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1.  SCOPE 

This  Acceptance  Test  Plan  (ATP)  establishes  the  plan  for  the  testing  of  the  Baseline 
Modular  Semi-Automated  Forces  (ModSAF)  for  Battlefield  Distributed  Simulation  - 
Developmental  (BDS-D)  sites.  This  document  has  been  developed  by  LORAL  Advanced 
Distributed  Simulation  under  contract  Number  N61339-91-D^001;  D.O.  0021,  Contract 
Data  Requirements  List  (CDRL)  A006,  in  accordance  with  paragraph  3.3  of  the 
Statement  of  Work  (SOW),  Baseline  SAF  for  BDS-D  Sites,  ModSAF. 

1.1  System  Overview 

The  purpose  of  the  ModSAF  environment  is  to  provide  a  Distributed  Interactive 
Simiilation  (DIS)  system  for  simulating  and  controlling  entities,  such  as  vehicles. 
Dismounted  Infantry  (DI),  missiles,  and  dynamic  structures  on  a  virtual  battlefield. 
These  entities  interact  with  each  other  and  with  manned  individual  entity  simulators, 
such  as  an  Ml  tank  simulator,  to  support  training,  combat  development  experiments, 
tactics  and  doctrine  studies,  weapon  and  sensor  evaluations,  and  man-machine  interface 
issues.  The  ModSAF  System  functions  in  an  established  simulation  system 
enviroiunent  at  the  Aviation  Test  Bed  (AVTB)  at  Ft.  Rucker,  Alabama,  and  the  Moimted 
Warfare  Test  Bed  (MWTB)  at  Ft.  Knox,  Kentucky.  The  purpose  of  this  test  plan  is  to 
define  the  test  program  which  will  verify  the  requirements  and  operation  of  the 
ModSAF  System  after  integration  with  the  existing  facilities.  Figure  1.0-1  reflects  the 
components  of  the  ModSAF  environment  which  are  applicable  to  the  ModSAF  delivery 
order.  Once  the  testing  of  the  ModSAF  software  has  b^n  completed  and  the  software 
and  documentation  referred  to  as  ModSAF  1.0  has  been  accepted  by  and  delivered  to 
the  Government,  configiuration  management  will  be  established.  It  is  anticipated  the 
ModSAF  software  and  dociunentation  will  be  delivered  to  multiple  Government  and 
industry  sites. 

ModSAF  comes  from  the  Advanced  Research  Projects  Agency  (ARP A)  What  If 
Simulation  System  for  Advanced  Research  and  Development  (WISSARD)  and 
"Seamless  Simulation"  programs.  ModSAF  restructures  the  SAFOR  baseline  to  make  if 
more  open,  more  modular  and  DIS  compliant.  In  addition  to  new  functionality 
developed  under  WISSARD,  ModSAF  1.0  focuses  on  providing  better  control,  more 
flexibility  and  extensions  to  higher  echelons,  and  full  documentation  of  the  ModSAF  1.0 
SAFOR. 

With  ModSAF,  the  operator  is  able  to  organize  forces  according  to  task,  transfer  control 
to  another  operator,  and  regroup  forces  for  new  tasks.  A  single  operator  has  the  ability 
to  command  vehicles  simulated  by  more  than  one  SAFOR  workstation.  It  is  also 
possible  to  checkpoint  and  restart  a  mission  without  re-tasking  the  forces.  Command 
and  control  information  is  recorded  along  with  exercise  information.  The  system 
provides  beyond  visual  range  air-to-air  combat  behavior,  and  includes  improved 
modeling  of  radar,  intervisibility  among  entities,  and  detection  probabilities.  The 
operator  can  plan  higher  level  and  more  flexible  missions  by  including  contingencies  for 
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known  and  expected  agents.  The  resulting  ModSAF  nins  under  DIS  1.0  protocol 
standards. 


I 


Figure  i.o>i  ModSAF  Envirpiuamt 


The  objectives  of  the  ModSAF  1.0  delivery  order  for  which  this  Acceptance  Test  Plan 
applies  are  as  follows: 


•  To  bring  SAFOR  systen\s,  both  hardware  and  software,  to  a  common 
baseline,  with  documentation  and  training  sufficient  to  p>ermit  BDS-D  site 
personnel  to  maintain  the  upgraded  systems. 

•  To  provide  additional  capabilities  including  new  battlefield  platforms  and 
functionality,  SAFOR  operator  toob,  and  better  system  performance. 

•  To  provide  all  of  the  capabilities  of  Ae  SAFOR  in  use  at  die  sites  at  the  time  of 
installation  of  the  ModSAF  Syston. 

•  To  provide  for  a  graceful  transition  path  from  ModSAF  to  Computer 
Generated  Forces  (CGF). 


The  purpose  of  this  ATP  is  to  provide  formal  test  procedures  for  acceptance  of  the 
ModSAF  System.  The  test  procures  verify  that  Ae  requirements  of  the  ModSAF 
Syston  have  been  met.  These  procedures  do  not  verify  and  validate  the  software 
modeb  of  individual  entities. 
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1.2  Document  Overview 

This  Acceptance  Test  Plan  is  organized  into  two  volumes  to  satisfy  the  CDRL  A006 
requirement.  Each  volume  is  a  stand-alone  document  and  consists  of  the  following 
sections: 

1.  Volume  I  -  This  Volume  of  the  Acceptance  Test  Plan  details  the  test  definitions  and 
test  philosophy  for  the  ModSAF  1.0  System  test  program.  The  following  sections 
constitute  this  volume: 

a.  Section  1  contains  an  overview,  purpose  and  brief  description  of  the  functionality 
of  the  ModSAF  System  environment. 

b.  Section  2  identifies  those  documents  which  are  applicable  and  have  been 
referenced  in  the  generation  of  this  document. 

c.  Section  3  provides  the  test  philosophy  and  approach  to  be  implemented  in  the 
verification  of  the  ModSAF  System  requirements  and  design.  The  tests  described 
in  this  section  will  be  the  basis  for  the  generation  of  the  Volume  II  document. 

d.  Appendix  .A  -  ModSAF  Requirements  Traceability  Matrix. 

e.  Appendix  B  -  Glossary  of  Acronjrms  and  Abbreviations. 

2.  Volume  II  -  This  volume  of  the  Acceptance  Test  Plan  contains  qualification  test 
preparations,  pre-test  procedures,  qualification  test  descriptions,  and  identification 
of  test  cases.  Finally,  the  volume  contains  the  detailed  step-by-step  procedures  to 
verify  the  ModSAF  System  requirements  as  defined  in  the  ModSAF  1.0  System 
Requirements  Specification  document.  The  allocation  of  requirements  to  each  test 
are  provided  in  Appendix  A  of  Volume  I  and  will  provide  the  traceability  to  the 
procedures  contained  in  this  volume. 
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2.0  APPUCABLE  DOCUMENTS 

The  following  documents  are  applicable  to  the  extent  referenced  herein  and  where  not 
specifically  r^erenced  are  used  as  sources  of  additional  information. 

1.  ModSAF  Systems  Requirement  Specification.  STRICOM,  12350  Research 
Parkway,  Orlando,  Florida  32826-3275,  dated  15  February  1993. 

2.  Statement  of  Work  for  the  Baseline  SAF  for  BDS-D  Sites,  Modular  Semi- 
Automated  Forces  (ModSAF),  dated  10  October  1992. 

3.  ModSAF  Installation  Plan.  STRICOM,  12350  Research  Parkway,  Orlando, 
Florida  32826-3275,  dated  12  February  1993. 

4.  ModSAF  Training  Plan.  STRICOM,  12350  Research  Parkway,  Orlando, 
Florida  32826-3275,  dated  12  February  1993. 

5.  ModSAF  Maintenance  Plan.  STRICOM,  12350  Research  Parkway,  Orlando, 
Horida  32826-3275,  dated  12  February  1993. 


3.0  TEST  PHILOSOPHY  AND  OBJECTIVES 

The  ModSAF  System  test  philosophy  is  to  verify  as  many  of  the  requirements  as 
possible  during  the  early  stages  of  the  testing  program.  This  approach  to  final 
acceptance  will  provide  the  benefits  of  surfacing  problems  early  in  the  testing  program 
which  will  also  enable  early  resolutions  of  the  problems.  This  approach  also  provides 
the  benefit  of  a  smooth  on-site  acceptance  test  phase  in  that  the  acceptance  test 
procedures  will  have  been  previously  exercised  and  procedural  problems  corrected  as 
applicable.  The  early  stages  of  the  testing  program  defined  as  the  In-House  Verification 
test  phase,  will  be  conducted  in  the  Loral  Advanced  Distributed  Simulations  (LADS) 
facility  located  in  Cambridge,  Massachusetts.  A  government-owned  IRIS  INDIGO 
system  will  be  configured  to  support  the  testing  of  the  requirements  associated  with  the 
ModSAF  System. 

A  ModSAF  Requirements  Traceability  Matrix  will  be  maintained  throughout  all  testing 
phases  which  ^1  provide  the  status  of  requirements  verified,  or  failed,  as  applicable. 
In  addition  to  the  Requirements  Traceability  Matrix,  a  Software  Problem  Report  (SPR) 
system  will  be  maintained  for  all  problems  surfaced  during  the  test  program.  The 
I^uirements  Traceability  Matrix  will  be  maintained  in  such  a  manner  that  the  SPRs  are 
completely  traceable  to  the  requirements  affected.  As  each  SPR  is  generated, 
assignment  will  be  made  by  the  ModSAF  System  delivery  order  manager,  or  his 
designated  representative,  as  to  whether  the  problem  is  procedural,  hardware,  software, 
or  a  system  problem.  Accordingly,  appropriate  personnel  will  be  assigned  to 
investigate  and  resolve  the  problem.  As  problems  are  resolved,  they  will  be  submitted 
for  re-test  before  becoming  part  of  the  "next"  official  baseline.  An  important  part  of  the 
ModSAF  System  test  program  will  be  "regression"  testing.  Continuous  regression 
testing  will  be  conduct^  throughout  the  test  program  to  ensure  that  as  new  resolutions 
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are  introduced  into  the  baseline,  previously  working  functions  have  not  been 
contaminated. 


The  primary  objective  of  this  plan  and  the  accompanying  test  procedures  (Vol  n)  is  to 
establish  that  the  ModSAF  System  is  in  compliance  with  ^e  requirements  as  delineated 
in  the  ModSAF  System  Requirements  document.  This  objective  is  best  achieved  by 
defining  tests,  development  of  test  procedures,  and  execution  of  these  tests  which  will 
thoroughly  verify  the  ModSAF  System  requirements. 


3.1  Test  Description 

The  ModSAF  System  is  comprised  of  four  subsystems  that  will  be  tested.  The 
subsystems  are  identified  as  follows: 

•  SAP  Workstation  Subsystem 

•  SAF  Simulator  Subsystem 

•  SAF  Logger  Subsystem 

•  ModSAF  Interface 

In  addition,  the  test  program  will  verify  aggregate  requirements. 

The  test  program  will  develop  test  procedures  with  the  objective  of  verifying  the 
aggregate  requirements  and  the  specific  requirements  pertaining  to  each  of  the  defined 
subsystems.  The  definition  of  tests  and  allocation  of  requirements  will  be  made  to 
provide  a  most  efficient  and  thorough  test  program.  This  will  be  accomplished  through 
analysis  of  the  requirements  and  existing  design  documentation  so  that  the 
requirements  can  be  correlated  to  the  functionality  of  the  subject  requirements. 
Independent  tests  and  procedures  will  be  defined  so  that  these  tests  can  be  executed 
independently.  The  independent  test  approach  will  provide  the  program  with  the 
flexibility  to  execute  the  tests  in  any  sequence  desired  and  remove  dependencies  where 
execution  of  functions  are  truly  independent  The  ModSAF  Requirements  Traceability 
Matrix  (Appendix  A)  identifies  the  allocation  of  requirements  to  the  tests  as  defined  in 
the  following  paragraphs: 

3.1.1  _ ModSAF  System  Overall  Requirements 

This  test  will  verify  the  overall  functional  requirements  of  the  ModSAF  1.0  System. 
Among  the  many  capabilities  that  will  be  tested  or  demonstrated  in  this  test  as  part  of 
the  ModSAF  1.0  System  Overall  Requirements  are: 

•  Architecture. 

•  Configurations. 

•  Top  Level  Requirements. 

•  Versions. 

•  Testability. 
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•  Extensibility. 

•  E>ocumentation. 

This  test  will  verify: 

1)  the  architecture  and  distribution  of  the  capabilities  of  ModSAF  among  three 
components, 

2)  sharing  of  simulation  and  control  information  by  using  databases  and  network 
protocols, 

3)  single  and  combined  system  operation, 

4)  control  of  simulated  entities  by  single  and  multiple  SAFstations, 

5)  creation  of  large  numbers  of  computer  generated  DIS  forces, 

6)  capabilities  that  equal  or  exceed  ^ose  of  the  currently  fielded  SAPOR  systems, 

7)  Version  1.0  requirements, 

8}  testability  of  operations  under  successively  simpler  conditions, 

9)  library  and  parameter  file  extensibility,  and 

10)  availability  of  ModSAF  documentation. 

2JL2 _ SAF  Workstation  Subsystem 

This  subsystem  test  will  demonstrate  the  capabilities  associated  with  the  SAF 
Workstation  Subsystem.  Conditions  will  be  set  up  to  ensure  verification  of  the 
following  capabilities: 

•  Mode  Control. 

•  Plan  View  Display. 

•  Exercise  Initiaib;ation  Parameters. 

•  Exercise  Control  Parameters. 

•  Scenario  Storage. 

•  Force  Control. 

•  Interaction  Between  Workstations. 

•  Databases. 

•  Standards. 

This  test  will  verify  the  functional  requirements  for  the  ModSAF  workstation.  This  test 
will  verify: 

1)  support  of  three  operator  privilege  modes, 

2)  a  two-dimensional  view  of  the  simulated  enviroiuneiit  including  control  tools, 

3)  parameter  control  for  an  exercise, 

4)  saving  of  all  mission  and  unit  information  into  a  scenario  file, 

5}  control  of  ModSAF  entities  and  units, 

6)  parameter  initialization  for  an  exercise, 

7)  control  of  aspects  of  the  user  interface, 

8)  ability  to  interact  with  other  workstations, 

9)  access  to  foe  numerous  databases,  and 
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10)  use  of  X/Windows  Motif  standards  and  DOD  Human  Computer  Interface  Style 
Guide. 

3x1.2. _ SAP  Simulator  Subsystem 

This  subsystem  test  will  demonstrate  the  capabilities  associated  with  the  SAP  Simulator 
Subsystem.  Conditions  will  be  set  up  to  ensure  verification  of  the  following  capabilities: 

•  Exercise  Control. 

•  Command  Interface. 

•  Entity  Simulation. 

•  Structure  Simulation. 

•  Unit  Simulation. 

•  Parser  Interface. 

•  Database  Interfaces. 

This  test  will  verify  the  functional  requirements  for  the  SAFsim  component  of  ModSAF. 
This  subsystem  will  verify: 

1)  entity  creation,  state  update,  deletion  and  migration, 

2)  monitoring  of  PO  database  for  entity  actions, 

3)  construction  of  new  entities  either  off-line  by  changing  parameter  files,  or  at  nm 
time  via  the  PO  database, 

4)  simulation  of  structures  on  the  terrain, 

5)  unit  simulation  including  combinations  of  entities,  or  entities  and  units, 

6)  parser  interface  for  SAF  software  testing,  and 

7)  database  interfaces. 

3.1.4  SAF  Logger  Subsystem 

This  subsystem  test  will  demonstrate  the  capabilities  associated  with  the  SAF  Logger 
Subsystem.  Conditions  will  be  set  up  to  ensure  verification  of  the  following  capabilities: 

•  Graphical  User  Interface  (GUI). 

•  Exercise  Recording. 

•  Exercise  Playback. 

•  Initialization  of  ModSAF  from  a  Logged  Exercise. 

This  test  will  verify  the  functional  requirements  for  the  ModSAF  data  logger.  This  test 
will  verify: 

1)  record  and  play  back  of  simulation  exercises, 

2)  creation  of  initialization  overlays, 

3)  use  of  graphical  user  interface  for  user  interaction, 

4)  recording  of  the  simulation  packets  of  any  protocol  family  transmitted  on  the 
simulation  network. 
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5)  playback  of  the  simulation  packets  of  any  protocol  family  recorded  in  a  ModSAF 
data  logger  fUe,  and 

6)  initialii'ation  of  ModSAF  from  any  point  in  a  logged  exercise  using  the  recorded 
PO  protocol  packets. 

3.1.5  ModSAFJnterface 

This  test  will  demonstrate  the  capabilities  associated  with  the  Interface  Requirements. 
Conditions  will  be  set  up  to  ensure  verification  of  the  following  capabilities: 

•  DIS  Database  Interface. 

•  PO  Database  Interface. 

•  Parameter  Database  Interface. 

•  Terrain  Database  Interface. 

This  test  will  verify  the  interfacing  of  ModSAF  components  via  the  DIS  database,  PO 
database,  parameter  database,  and  the  terrain  database.  This  test  will  verify: 

1)  the  support  of  DIS  1.0  protocol,  with  appropriate  extensions, 

2)  the  support  of  SIMNET  6.6.1  protocol, 

3)  PO  database  support,  including  organization  of  command  and  control 
information  as  shared  overla)rs, 

4)  ability  to  modify  the  parameter  database  to  define  entity  characteristics,  and 

5)  terrain  database  queries  and  modifications. 
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Requirements  Traceability  Matrix 

f 

i 

Test  Methodologies: 

Isinspection — ^Verification  by  visual  examination  of  the  displa)^,  reviewing  descriptive 
documentation,  and  comparing  the  appropriate  characteristics  with  a  reference 
standard,  to  determine  conformance  to  requirements.  This  includes  mechanical 
inspection  of  equipment  and  the  verification  of  accuracy  and  completeness  of  the 
documentation. 

A=Analysis — ^Verification  by  evaluation  using  data  sheets  gathered  from  test 
participants,  mathematical  representations,  charts,  graphs,  or  data  reduction  to 
determine  conformance  to  requiiements. 

D=I>emonstration — ^Verification  by  operation,  movement,  or  adjustment  of  the  item 
imder  specific  conditions  to  perform  the  designed  fimction  to  determine  conformance  to 
the  requirements.  This  includes  content  and  accuracy  of  displays,  and  prompt  system 
recovery  from  induced  failure  conditions. 

R=Reliability-Not  verified  by  Demonstration  or  Test.  Verified  as  the  byproduct  of 
reliability  and  documentation  testing  by  ILS  personnel  and/or  engineering  resources. 

T=Test — Verification  through  systematic  exercising  of  the  applicable  items  under 
appropriate  conditions,  with  instrumentation  and  collection,  analysis,  and  evaluation  of 
quantitative  data  to  determine  conformance  to  requirements.  This  includes  correct 
computer  program  control  flow,  correct  computer  program  data  flow,  and  acceptance  of 
proper  range  of  values. 
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The  ModSAF  components  will  share 
simulation  and  control  information 
by  using  the  databases  and  network 
protocols  described  below:  DIS 
Database,  Persistent  Object  (PO) 
Database,  Terrain  Databases,  and 
Parameter  Database. 


A  single  computer  will  be  able  to 
run  one  of  the  SAFstation,  SAFsim, 
or  SAF- logger  components  at  a 
time . 


A  single  computer  will  be  able  to 
run  both  the  SAFstation  and  SAFsim 
at  the  same  time. 


Multiple  SAFstations  will  be  able 
to  control  entities  simulated  by 
one  SAFsim. 


One  SAFstation  will  be  able  to 
control  entities  simulated  on 
multiple  SAFsims. 


The  SAFsims  will  act  as  simulation 
servers  and  will  negotiate  between 
themselves  which  SAFsim  should 
simulate  an  entity,  unless  one 
SAFsim  has  been  specifically 
designated. 


The  SAFsim  will  not  have  to 
connect  to  a  SAFsim  but  will 
communicate  with  all  SAFsims  via 
the  Persistent  Object  Database. 


ModSAF  will  provide  the  capability 
to  create  large  numbers  of 
computer  generated  DIS  forces  that 
can  be  controlled  by  small  numbers 
of  operators  providing  supervisory 
control . 


It  will  provide  capabilities  that 
equal  or  exceed  those  of  the 
currently  fielded  SAFOR  systems: 
SIMNET  SAF  3.11.2  and  ODIN  SAF 
4.3.6. 


ModSAF  will  provide  support  for 
the  WISSARD  project,  including 
interfaces  for  control  by  the  SOAR 
artificial  intelligence  reasoning 
svstem. 


MBTH  TEST 


I 


I 

I 
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The  ModSAF  software  will  be 
capable  of  running  on  MIPS  and  SGI 
computers . 


ModSAF  will  be  delivered  in 
incremental  versions:  ModSAF  A, 
ModSAF  B.  ModSAF  1.0,  ModSAF  2.0. 


The  ModSAF  software  will  be 
constructed  so  that  it  is  possible 
to  test  its  operation  under 
successively  simpler  conditions. 
There  will  be  mechanisms  by  which 
complicating  factors  such  as 
communications  failures, 
occlusion,  collisions,  random 
failures,,  etc.,  can  be  eliminated. 


All  other  routines  will  be 
declared  static. \ 


ModSAF  will  parameterize  both 
behavioral  and  physical  models  so 
that  a  variety  of  physical  systems 
can  be  represented! 


At  program  startu 
line  parameter  da 
defines  these  par 
tra 


During  runtime,  the  user  or  the 
system  will  be  allowed!  to  change 
this  database  for  the  purpose  of 
making  changes  to  models  without 
forcing  a  recompilation\pf  source 
code .  \ 


Documentation  ModSAF  documentation  willy  be 

available  in  both  hardcop^^  and  on¬ 
line  format  on  the  ModSAF  \ 
development  computers .  \ 
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ModSAF  documentation  will  include: 
Requirements  Document,  Interface 
Description  Document,  Library 
Documentation,  User's  Manual, 
Installation  Instructions,  and 
Maintenance  Plan. 

I 

2.1 

Mode  Control 

The  SAFstation  will  support  three 
operator  privileqe  modes. 

D 

2.1 

The  highest  privilege  mode.  System 
Operator,  will  provide  more 
functionality  than  the  lower  two 
privilege  modes,  Battlemaster  and 
Commander . 

D 

2.1 

SAF 

Workstation 

Requirements 

This  ModSAF  component  will  allow  a 
user  to  set  up,  view,  control,  and 
participate  in  DIS  exercises. 

D 

2.1 

The  middle  privilege  mode, 
Battlemaster,  will  provide  more 
functionality  than  the  lowest 
privileqe  mode.  Commander. 

D 

2.1.1 

Commander 

Mode 

Commander  mode  will  provide  the 
ability  to  run  a  pre-load  scenario 
and  to  command  the  commanders'  S7VF 
entities  in  that  scenario. 

D 

2.1.1 

In  Commander  mode,  the  situation 
display  will  show  only  the 
entities  on  the  same  side  as  the 
entities  controlled  by  the 
commander,  and  any  enemy  entities 
detected  by  the  commander's 
entities . 

D 

2.1.2 

Battlemaster 

Mode 

In  Battlemaster  mode,  the  SAF 
operator  will  be  able  to  create 
and  save  scenarios,  in  addition  to 
having  all  the  capabilities 
provided  in  Commander  mode. 

D 

2.1.3 

System 

Operator  Mode 

System  Operator  mode  will  allow 
the  SAF  operator  to  perform  file 
operations  such  as  delete  and 
save,  in  addition  to  providing  all 
the  functionality  of  Battlemaster 
mode . 

D 

2.1.3 

In  System  Operator  mode,  the  SAF 
operator  will  have  the  ability  to 
set  all  passwords  and  modify  the 
simulation  confiqurations. 

D 

2.2 

Plan  View 
Display 

The  SAFstation  will  provide  a  two- 
dimensional  view  of  the  simulated 
environment  (the  so-called  Plan 

View  Display),  along  with  various 
tools  for  controlling  the  view 
onto  the  environment  and 
determining  which  features  are 
displayed  in  it. 

D 
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Controlling 
the  Display 

The  SAFstation  operator  will  be 
able  to  control  the  view  of  the 
simulated  environment  as  described 
below. 

D 

■ 

Panning 

The  SAFstation  will  provide  the 
ability  for  the  operator  to  pan, 
that  is,  to  select  any  portion  of 
the  map  for  displav. 

■ 

1 

■ 

The  operator  will  be  able  to  pan 
by  using  scroll  bars,  by  dragging 
a  viewing  window  with  the  mouse, 
or  by  clicking  with  the  mouse  on  a 
new  map  center. 

D 

■1 

Changing  the 
Scale 

A  Scale  menu  will  allow  the 
operator  to  change  the  scale  of 
the  tactical  map  displav. 

D 

m 

The  Scale  menu  will  display  the 
current  scale  and  provide  the 
ability  to  select  a  different 
scale . 

D 

m 

The  operator  will  be  able  to 
choose  whether  the  map  scale  is 
restricted  to  standard  map  scales 
or  can  be  freely  adiusted. 

D 

■ 

Zooming  In 
and  Out 

The  SAFstation  will  allow  the 
operator  to  zoom  in  on  a  small 
portion  of  the  tactical  map  or 
zoom  out  to  a  large  portion  by 
clicking  once  with  the  mouse  on 
the  map. 

D 

■ 

The  SAFstation  will  allow  the 
operator  to  use  the  mouse  to 
select  a  rectangular  area  to  zoom 
in  upon. 

D 

2.2.2 

Displaying 
the  Terrain 

The  SAFstation  will  allow  the 
operator  to  determine  which 
terrain  features  are  currently 
displayed  (roads,  trees,  lakes, 
etc . ) . 

D 

2.2.2 

It  will  allow  the  operator  to 
select  the  terrain  features 
displayed,  the  elevation 
presentation  (by  shaded  relief, 
hypsometric  tinting,  or  contour 
lines),  and  which  military  grid 
system,  if  any,  to  use. 

1 

1 

■ 

Features 

The  terrain  features  available  for 
display  on  the  tactical  map 
display  will  include,  but  not  be 
limited  to  roads,  trees,  tree 
canopies,  rivers,  lakes, 
buildings,  railroads,  pipelines, 
and  power  lines. 

D 
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2. 2. 2. 2 


2. 2. 2. 2 


2. 2. 2. 3 


2. 2. 2. 3 


2. 2. 2. 3 


TITLE 


Elevation 


Military 

Grids 


Analyzing  the 
Terrain 


2.2.3. 


Terrain  Ruler 


DB8CRI»TI<»t 


The  operator  will  be  able  to 
display  elevation  by  the  following 
two  methods:  hypsometric  tinting 
and  contour  lines. 


The  operator  will  be  able  to 
display  elevation  by  colors. 


A  legend  will  specify  the 
elevation  range  of  each  color. 


The  operator  will  be  able  to 
display  elevation  by  contour  lines 
with  or  without  labels  showing  the 
elevation  values. 


The  operator  will  be  able  to  set 
the  contour  interval  at  any  time, 
from  5  to  40  meters,  in  increments 
of  5  meters. 


The  interval  selected  will  be 
displayed. 


The  SAFstation  operator  will  be 
able  to  overlay  a  grid  system  on 
the  map  in  either 
longitude/ latitude  or  UTM  form. 


The  grids  will  be  shown  at  a  scale 
appropriate  for  the  current  map 
scale . 


At  the  1:200,000  map  scale,  one¬ 
digit  UTM  grids  will  be  shown, 
while  at  the  1:50,000  map  scale, 
two-digit  UTM  grids  will  be  shown. 


The  SAFstation  will  provide  the 
following  tools  to  allow  the  SAF 
operator  to  analyze  the  current 
terrain  database:  terrain  ruler, 
cross-section  tool, 
intervisibility  tools,  terrain 
query  tool  and  coordinate 
calculator. 


the 


2. 2. 3. 2 


The  operator  will  have  the  ability 
to  specify  the  units  in  which  the 
distance  is  measured. 


The  direction  of  the  ruler  will  be 
displayed. 


Cross-Section  A  terrain  cross-section  tool  will 
Tool  allow  the  operator  to  display  the 

difference  in  elevation  between 
two  terrain  points  specified  by 
the  operator. 


I 

I 

I 
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2. 2. 3. 2 

The  length  and  direction  of  the 
cross-section  line  dram  between 
the  specified  points  will  be 
displayed;  the  composition  of  the 
terrain  will  not. 

D 

2. 2. 3. 3 

Inter¬ 

visibility 

Tool 

Inter-visibility  tools  will  allow 
the  operator  to  do  the  following: 

(1)  check  the  inter-visibility 
between  individual  entities,  (2) 
check  the  inter-visibility  between 
points  on  the  terrain,  and  (3) 
check  the  area  inter-visibility 
around  a  location. 

D 

2. 2. 3. 3 

The  operator  will  be  able  to 
specify  how  high  above  the  terrain 
the  inter-visibilitv  is  measured. 

D 

2. 2. 3. 3 

For  air  vehicles,  the  altitude  of 
the  vehicle  will  be  used  as  the 
height  at  which  the  inter- 
visibilitv  is  measured. 

D 

2. 2. 3. 3 

For  ground  entities,  the  elevation 
of  the  commander  or  driver  will  be 
used  as  the  height  at  which  the 
inter-visibilitv  is  measured. 

D 

2. 2. 3. 3 

The  operator  will  be  able  to  set 
the  range  for  area  inter- 
visibilitv  plots. 

D 

2. 2. 3. 4 

Terrain  Query 
Tool 

The  operator  will  be  able  to  query 
the  tactical  map  at  any  location 
to  determine  the  soil  type 
(RCI250,  road,  water,  etc.), 
elevation,  maximum  gradient,  and 
location . 

D 

2. 2. 3. 5 

Coordinate 

Calculator 

A  coordinate  calculator  will  allow 
the  SAF  operator  to  select  a  point 
on  the  map  and  calculate  its 
location  in  earth  centered 
Cartesian,  UTM, 
longitude/latitude,  and 
topocentric  Cartesian  coordinates. 

D 

2.2.4 

Displaying 
the  Situation 

The  Plan  View  Display  will  be  able 
to  show  the  current  situation  in 
an  exercise  by  displaying  the 
current  positions  of  all  entities 
involved  in  the  exercise. 

D 

2.2.4 

It  will  be  possible  to  use  the 
parameter  files  described  in 

Chapter  5  to  change  the  icons  used 
to  denote  units  and  entities,  or 
to  add  new  icons. 

D 

2.2.4 

The  operator  will  be  able  to 
specify  the  refresh  rate  of  the 
entity  icons  on  the  situation 
display,  from  1  to  120  seconds. 

D 
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2. 2. 4. 2  I  Entities 


2. 2. 4. 2 


2. 2. 4. 2 
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be  a 
ity  i 


Army  symbology  and  Navy  symbology 
will  be  used  to  display  military 
units . 


The  operator  will  be  able  to 
choose  which  symbology  takes 
precedence  when  both  are 
applicable. 


The  Army  symbology  will  be  defined 
by  *FM  101-5:  Operational  Terms 
and  Graphics. 


It  will  be  possible  to  query  the 
unit  icons  to  get  a  description  of 
the  unit  they  represent. 


This  description  will  include  the 
entity  ID  and  designation  for  the 
unit . 


It  will  be  possible  to  aggregate 
the  display  to  show  only  higher- 
level  units  or  deaggregate  it  to 
show  individual  entities. 


Aggregation/deaggregation  will  be 
possible  either  globally  or  for 
individual  units. 


Filters  will  allow  the  operator  to 
control  the  display  of  different 
force  types,  including  armor, 
infantry,  artillery,  air  defense, 
support,  air  assets,  and  sea 
assets . 


A  filter  will  allow  control  of 
whether  the  operator  can  see  what 
all  of  his  forces  can  see,  or  only 
what  some  subset  of  his  forces  can 
see . 


Individual  entities  may  be 
displayed  by  the  standard  military 
symbology  of  "FM  101-5: 

Operational  Terms  and  Graphics, * 
or  they  may  be  displayed  in  a  non- 
militarv  form. 


The  standard  military  form  will 
show  entity  direction  quantized  to 
8  directions  (45  degrees),  while 
the  non-military  form  will  show 
exact  entity  and  turret 
orientations . 


Both  forms  will  show  catastrophic 
entity  damage. 


I 

I 
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It  will  be  possible  to  query  the 
entity  icons  to  get  a  description 
of  the  entities  they  represent. 


This  description  will  include  the 
entity  ID  and  designation  for  the 
entity  and,  if  the  entity  is  being 
controlled  by  the  SAFstation 
making  the  query,  the  current 
status  of  that  entity,  including 
information  about  fuel  and 
ammunition  supplies,  speed, 
mission  status,  and  damage  level. 


It  will  be  possible  to  display 
inter-visibility  lines  between 
entities . 


When  an  entity  is  only  partially 
visible,  the  percentage  that  is 
visible  will  be  indicated  by  the 
color  of  the  intervisibility  line 
and  by  text  field  showing  the 
percentage . 


The  SAF  operator  will  be  able  to 
specify  designations  for  units  and 
entities  and  specify  whether  to 
displav  these  designations. 


If  the  SAF  operator  does  not 
specify  a  designation  for  an 
entity  or  unit,  ModSAF  will  supply 
a  default  designation. 


The  SAFstation  will  display 
simulation  events  such  as  indirect 
fire  explosions. 


The  SAFstation  will  also  display 
direct  fire,  designating  the 
target  and  firer  and  whether  the 
shot  was  a  hit  or  a  miss. 


The  SAFstation  will  also  display 
minefield  explosions. 


Any  SAFstation  will  be  able  to 
initialize  the  parameters  for  an 
exercise. 


When  the  System  Operator  sets  the 
terrain  database  for  the  exercise, 
all  workstations  and  simulators 
will  change  to  the  selected 
terrain. 
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Storage 
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Changing  the  terrain  will  cause 
running  simulations  to  stop. 


Any  SAFstation  will  be  able  to 
control  the  parameters  for  an 
exercise. 


The  exercise  control  functions 
will  be  available  only  in 
Battlemaster  mode. 


The  Battlemaster  will  be  able  to 
create  minefields  from  the 
SAFstation  at  anv  time. 


The  Battlemaster  will  be  able  to 
draw  the  bounding  area  of  the 
minefield  and  then  request 
simulation  of  the  minefield  from 
the  SAFsim. 


He  will  be  able  to  specify 
minefield  parameters  such  as 
density  and  type  of  mine. 


The  Battlemaster  will  be  able  to 
interactively  create  artillery 
bursts  in  any  location  or  area  on 
the  terrain. 


Various  options  will  be  available, 
such  as  number  of  rounds, 
dispersal  pattern  and  distance, 
rate,  round  types,  and  time  delays 
between  rounds. 


B«nbs,  mortars,  howitzers,  and 
MLRS  will  be  available. 


Timed/proximity  and  contact  fuses 
will  be  available. 


It  will  be  possible  to  set  up 
multiple  missions  so  that 
artillery  can  fall  at  a  specified 
time  during  an  exercise. 


T 


It  will  be  possible  to  apply  a 
single  set  of  pareuneter  changes  to 
multiple  SAF  units  without 
duplicate  data  entry. 


The  ModSAF  system  will  all  the 
Battlemaster  to  save  all  mission 
and  unit  information  into  a 
scenario  file. 
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This  file  will  contain  information 
about  all  entities,  units,  unit 
hiearchies,  missions,  tasks, 
control  measures,  and  artillery 
scripts  that  are  currently 
controlled  by  the  workstation  or 
that  were  created  bv  it. 

D 

2.5 

This  file  will  allow  a  new 
exercise  to  be  initialized  at  the 
point  at  which  the  previous 
exercise  was  saved. 

D 

2.6 

Force  Control 

The  operator  will  be  able  to  give 
orders  to  any  unit  or  entity 
directlv  bv  clickina  on  its  icon. 

D 

2.6.1 

Task 

Organization 

The  operator  will  be  able  to 
create  and  consnand  units  from  the 
battalion  level  down  to  the 
individual  entity  level. 

N/I 

2.6.1 

It  will  be  possible  for  the 
operator  to  create  new  tactical 
organizations  on  line,  using  the 
standard  graphical  user  interface, 
without  modification  to  the 
underlying  software. 

N/I 

2.6.1 

It  will  be  possible  to  use  the  new 
task  organizations  in  the  standard 
command  and  control  mechanism. 

N/I 

to 

The  units  will  be  built  up  in  a 
hierarchical  and  modular  way, 
allowing  the  operator  to  mix 
branches  (e.g.,  armor,  close  air 
support,  artillery,  and  infantry) 
and  equipment  nationalities  (e.g., 
US  armor  vehicles  with  Russian 
armor  vehicles) . 

N/I 

2.6.1 

Formations  and  movement  techniques 
will  be  defined  in  a  similarly 
modular  way,  so  that  they  will 
work  with  the  task-organized 
units. 

N/I 

2.6.1 

It  will  be  por.sible  to  save  the 
task  organizations  to  a  data  file 
for  reuse  in  other  scenarios. 

N/T 

2.6.1 

It  will  be  possible  to  construct 
formations,  movement  techniques, 
and  missions  in  a  hierarchical 
manner . 

N/I 

2.6.2 

Methods  of 
Control 

Three  methods  of  control  will  lae 
available  to  the  operator;  pre¬ 
programmed,  immediate,  and 
reactive. 

D 

2.6.2 

Pre-programmed  and  immediate 
control  will  be  available  to  the 
operator  at  any  time. 

D 
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Control 


2. 6. 2. 2 


2. 6. 2. 2 


2. 6. 2. 3  Reactive 
Control 


vmaeKmicm 


without  further  operator 
interventions,  the  subordinate 
unit  will  perform  its  mission, 
while  the  senior  unit  adjusts  its 
formations  and  actions  in 
tactically  realistic  ways  to 
accommodate  the  loss  of  the 
subordinate  unit. 


TEST 


The  operator  will  be  able  to 
specify  tasks  that  specify 
movement  of  units  along  a  single 
path,  as  well  as  tasks  that 
specify  movement  of  units  along 
different  paths. 


Within  each  mission  or  mission 
phase,  the  operator  will  be  able 
to  redefine  behavior  and 
capability  parcuneters  for  the  unit 
or  entity. 


Pareuneters  controlled  will  include 
at  least  the  following:  speed, 
formation,  orientation,  fire 
permission,  marksmanship,  target 
priorities,  fuel  consumption 
rates,  priorities  for  different 
simultaneous  objectives  (such  as 
finding  the  enen^,  avoiding 
detection,  moving  rapidly,  and 
surviving) ,  task,  and  entity 
pareuneters  (such  as  vulnerability, 
turn  radii,  sensor  capabilities, 
speed  and  acceleration  limits,  and 
weapons  capabilities)  . _ 


Immediate  control  will  allow  the 
operator  to  give  commands 
interactively  to  override  either 
pre-progreunmed  or  reactive 
behaviors . 


The  operator  will  have  the  option 
of  either  overriding  previous 
commands  or  temporarily  suspending 
them  until  the  immediate  comnand 
is  completed. 


Par^uneters  under  imnediate  control 
will  include  at  least  the 
following:  speed,  formation, 
orientation,  fire  permission, 
marksmanship,  target  priorities, 
and  task. 


The  operator  will  be  able  to 
specify  the  reactive  behavior  of 
units . 
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2.6.3  Mission 
Graphics 


2. 6. 3.1  I  Overlays 


2.6.3. 


2.6.3. 


2.6.3 


2 . 6 . 3 . 2  Graphical 
Control 
Measures 


2. 6. 3. 2 


2. 6. 3. 2 


2. 6. 3. 2 


2. 6. 3. 2 


2. 6. 3. 2 
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This  will  be  accomplished  by 
allowing  the  operator  to  select  a 
set  of  situations  and  battlefield 
events  to  which  the  units  will 
respond  (e.g.,  artillery  attack), 
modify  the  par2uneters  of  those 
situations  and  events  (e.g., 
artillery  has  fallen  within  1  km 
of  the  unit),  and  specify  the 
unit's  reaction  to  each  situation 
or  event  (e.g.,  withdraw  5  km  away 
from  the  artillery  bursts) . 


The  SAFstation  will  provide 
graphical  symbols  for  the  planning 
of  missions. 


MBTR  TEST 


D 


The  SAFstation  operator  will  be 
able  to  edit,  save,  load,  and 
delete  these  overlays. 


Overlays  can  be  shared  l>etween 
SAFstations,  although  controls 
will  be  placed  on  which 
workstations  can  share  overlays 
(based  on  which  side  the 
workstations  are  playing  in  an 
exercise) . 


The  SAFstation  will  provide  the 
capability  to  show  or  hide 
specific  overlays  to  allow  the 
operator  to  superimpose  graphics 
on  the  tactical  display. 


The  SAFstation  will  be  able  to 
create  and  edit  the  following 
graphical  control  measures: 
routes,  points,  lines,  areas  and 
zones ,  and  text . 


Routes  —  The  SAFstation  will 
provide  the  ability  to  create 
routes  for  SAF  entities  to  follow 
during  missions,  including 
circular  routes. 


The  SAFstation  operator  will  t>e 
able  to  create,  edit,  and  delete 
routes . 


In  addition,  the  ability  to  add 
points  to  the  end  of  a  route  will 
be  provided. 


Air  routes  —  will  insert  straight 
line  routes  between  operator- 
specified  points. 
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2. 6. 3. 2 

Road  routes  —  will  determine  the 
shortest  sequence  of  road  segments 
between  operator-specified  road 
points . 

D 

2. 6. 3. 2 

Cross-country  routes  —  will  check 
for  water  crossings  and  allow  the 
operator  to  have  the  route 
modified  to  avoid  the  water. 

D 

2. 6. 3. 2 

Bridge  routes  —  will  allow  the 
operator  to  select  a  bridge  to 
cross  as  part  of  a  cross-country 
route . 

D 

2. 6. 3. 2 

Points  —  The  SAFstation  operator 
will  be  able  to  place  the 
following  types  of  points: 
general,  coordinating,  contact, 
control,  target  reference, 
fortification,  decision,  hide,  and 
launch  points . 

D 

2. 6. 3. 2 

Lines  —  The  SAFstation  operator 
will  be  able  to  place  the 
following  types  of  lines:  plain, 
front,  minefield,  fortification, 
berm,  antitank  ditch,  and  wire. 
Lines  can  be  used  to  define  other 
military  control  measures,  such  as 
unit  boundaries,  objectives,  and 
phase  lines. 

D 

2. 6. 3. 2 

Areas  and  zones  —  The  SAFstation 
operator  will  be  able  to  place 
areas  and  zones .  These  can  be 
used  to  define  assembly  areas, 
battle  positions,  and  other 
militarv  area  control  mp-asurcs. 

D 

2. 6. 3. 2 

Text  --  The  SAFstation  operator 
will  be  able  to  place  multiple 
lines  of  text  on  the  display. 

D 

2. 6. 3. 2 

These  control  measures  can  be  used 
in  the  mission  specifications  for 
units  and  entities.  Various 
colors  will  be  provided  for  each 
control  measure  type,  including 
black,  yellow,  red,  green,  and 
blue.  Solid  or  dashed  lines  can  be 
used  for  all  line,  area,  and  zone 
control  measures. 

D 

2. 6. 3. 2 

The  operator  will  be  able  to  move 
any  control  measure  as  a  whole  or 
move  any  of  the  individual  points 
that  define  a  control  measure.  The 
operator  can  add  points  to  and 
delete  points  from  any  control 
measure  or  delete  it  entirely.  The 
operator  can  add  labels  to  control 
measures  and  edit  the  labels. 

D 
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2.6.^  I  Message  Log 


2.6.5  I  H-Hour  Time 


2.6.5 


2.6.6  I  Resupply 


2.6.6 


2.6.6 
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The  SAFstaCion  will  provide  a 
message  log  that  will  display 
status  messages  and  reports  from 
the  simulated  entities  and  units 
under  its  control . 


A  radio  log  will  show  orders 
issued  to  the  simulated  entities 
and  units  from  that  SAPstation. 


The  operator  can  control  the 
frequency  with  which  messages  are 
sent,  and  which  reports  are  sent. 


The  SAPstation  will  provide  the 
ability  to  set  an  H-Hour  Time,  so 
that  all  SAP  entities  can  perform 
coordinating  actions. 


This  H-Hour  time  can  be  modified, 
and  it  can  be  shared  among 
workstations  fighting  on  the  same 
side. 


The  SAPstation  will  provide  a 
method  for  setting  the  fuel  levels 
and  weapons  loads  of  entities  at 
resupplv  locations. 


Airport  locations  for  fixed-wing 
aircraft  and  PARP  locations  for 
rotary-wing  aircraft  must  be 
specified  by  the  Battlemaster .  The 
airport  locations  can  be  on  or  off 
the  terrain  database. 


The  resupply  locations  can  be 
shared  among  SAPstations  and  can 
be  saved  in  overlays. 


Ground  entities  will  be  resupplied 
through  logistics  vehicles  in  the 
simulation . 


The  Battlemaster  will  be  able  to 
resupply  any  SAP  unit  or  entity  at 
anvt ime . 


The  SAPstation  operator  will  be 
able  to  perform  the  following 
operations  with  any  SAPview 
component  or  Stealth  (Plying 
Carpet)  on  the  simulation  network: 
(1)  Teleport  the  SAPview  to  any 
location  on  the  database  and  (2) 
Attach  the  SAPview  to  any  entity 
under  his  command,  using  a  number 
of  attachment  modes. 


These  operations  may  be  used  to 
control  other  three-dimensional 
displays,  such  as  the  ODIN  Plying 
Carpet . 


The  use  of  the  SAPview  will  be 
restricted  in  Commander  mode. 
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When  the  SAFview  is  not  integrated 
with  another  ModSAF  application, 
the  operator  will  be  able  to 
change  the  exercise  ID  of  the 
SAFview . 


When  the  SAFview  is  integrated,  it 
will  use  the  exercise  ID  selected 
for  the  application. 


The  current  velocity  and  direction 
of  travel  of  the  SAFview  will  be 
displaved. 


An  icon  on  the  situation  display 
will  indicate  the  location  and 
viewing  direction  of  each  SAFview 
on  the  network. 


The  SAFstation  will  provide  a 
status  panel  that  displays  a 
continuous  update  of  the  mission 
and  energy  status  of  any  single 
aircraft  specified  by  the 
operator . 


The  operator  will  be  able  to  set 
the  following  aspects  of  the  user 
interface  according  to  his 
preference:  Numerical  units. 
Symbology  used  to  represent 
entities.  Grid  units,  and  Editing 
mode  for  control  measures. 


These  operator  settings  can  be 
saved  to  a  file  and  later 
retrieved  and  edited. 


They  can  be  overridden  by  the 
operator  on  a  case-bv-case  basis. 


The  operator  will  be  able  to 
choose  the  units  used  for  the 
following:  distance,  altitude, 
speed,  and  angles. 


Distance  —  used  for  all  distance 
displays,  messages,  and  operator 
inputs.  The  available  units  will 
be  feet,  meters,  nautical  miles, 
and  kilometers. 


Altitude  —  used  for  all  altitude 
displays,  messages,  and  operator 
inputs.  The  available  units  will 
be  feet,  meters,  nautical  miles, 
and  kilometers. 


Speed  —  used  for  all  speed 
displays,  messages,  and  operator 
inputs.  Available  units  will 
include  knots,  miles  per  hour, 
meters  per  second,  mach,  and 
kilometers  per  hour. 
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Transferring  control  —  Each 
SAFstation  will  be  able  to 
transfer  control  of  entities  and 
units  to  any  other  SAFstation.  In. 
Commander  mode,  the  transfer  must 
be  initiated  from  the  SAFstation 
currently  controlling  the  units  or 
entities.  In  Battleroaster  mode, 
the  control  of  any  unit  can  be 
transferred  to  the  local 
SAFstation  or  to  any  remote 
SAFstation. 


Sharing  an  exercise  time  — 
SAFstations  on  the  same  side  in 
the  exercise  can  share  an  H-Hour. 


The  SAFstations  will  have  access 
to  the  DIS,  PO,  Terrain  and 
Parameter  databases,  as  described 
in  Chapter  5.  The  DIS  database  is 
used  to  determine  the  locations, 
velocities,  and  physical 
conditions  of  entities.  The  PO 
Database  is  used  to  share  command 
and  control  as  well  as  system 
information  eunong  the  SAFstations 
SAFsims,  and  SAF-loggers. 


For  maximum  portability,  the 
ModSAF  graphical  user  interface 
will  be  built  using  X/Windows  and 
Motif . 


The  ModSAF  user  interface  will  be 
compliant  with  the  draft  DOD  Human 
Computer  Interface  Style  Guide,  11 
February  1992,  prepared  by  the 
Common  Operating  Environment 
Working  Group. 


ModSAF  will  provide  the  SOAR 
program  with  the  capability  to 
control  aircraft  movement, 
sensors ,  and  weapons . 


Each  SAFsim  will  receive  creation 
reqijests  through  the  Persistent 
Object  database  from  the 
SAFstations  when  the  operator 
requests  simulation  of  SAF 
entities  or  units. 


All  eligible  SAFsims  on  the 
simulation  network  will  negotiate 
with  each  other  to  decide  which 
SAFsim  should  simulate  that 
entitv. 


The  selected  SAFsim  will  create 
and  control  that  entity  until  told 
to  delete  or  transfer  it. 


1  ItilixJi  1 
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Entity  State 


Entity 

Deletion 


Entity 

Migration 


Entity 

Simulation 


The  SAFsim  will  update  the  DIS  and 
PO  databases  when  the  state  of 
the  entities  it  is  simulating 
changes.  This  information 
includes  the  positions,  damage 
level,  amount  of  fuel  and 
ammunition,  and  marksmanship 
level . 


The  SAFsim  will  support  the 
deletion  of  entities  that  it  is 
simulating.  Only  the  SAFstation 
controlling  the  entity  can  request 
its  deletion. 


A  SAFsim  will  transfer  simulation 
of  an  entity  to  another  SAFsim 
when  requested  by  the  entity's 
commander . 


Each  SAFsim  will  also  monitor  the 
state  of  all  other  SAFsims  on  the 
network . 


If  a  SAFsim  drops  off  the  network, 
the  remaining  SAFsims  will 
negotiate  with  each  other  to  take 
control  of  the  entities  being 
simulated  by  that  SAFsim. 


The  load  will  be  balanced  among 
the  remaining  SAFsims  to  the  best 
possible  extent. 


Each  SAFsim  will  check  the  PO 
database  for  actions  that  its 
entities  are  asked  to  execute. 


The  SAFsim  will  then  notify  the 
unit  of  the  presence  of  the 
mission,  frago,  or  immediate 
command  and  allow  the  unit  to 
decide  how  to  respond  to  it. 


The  SAFsim  will  also  put 
subordinate  missions  generated  by 
its  simulated  entities  in  the  PO 
database  for  execution  by  the 
entity's  subordinates. 


Missions  generated  locally  will  be 
handled  in  exactly  the  same  way  as 
remotely  generated  missions. 


The  SAF  simulation  models  will 
emphasize  efficiency  and  avoid 
simulating  those  behaviors  and 
mechanisms  that  do  not  produce 
significant  externally  visible 
signatures. 


Many  SAF  models  will  include 
simple  elements  of  human  control 
that  effectively  simplify  the 
behavior  of  the  entities. 
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3.3 

The  SAFsia  will  allow  the 
constiruction  of  new  entities 
either  off-line  by  changing 
parameter  files  or,  at  run  time, 
via  the  Persistent  Object 
database . 

I 

3.3.1 

Entity  Hull 
Simulation 

The  following  hull  dynamics  models 
will  be  available:  ground  vehicle 
tracked,  ground  vehicle  wheeled, 
dismounted  infantry,  fixed  wing 
aircraft,  rotary  wing  aircraft, 
and  missiles. 

I 

3.3.1 

Specific  fuel  consumption  models 
will  apply  to  vehicles  based  on 
the  hull  dynamics  model. 

I 

3.3.1 

Vehicles  will  start  with  a 
standard  amount  of  fuel  per 
vehicle,  which  will  be  defined  in 
the  vehicle  parameter  database. 

I 

3.3.1 

Fuel  consumption  rates  will  be 
determined  by  the  specific  vehicle 
dynamic  model  being  used. 

I 

3.3.1 

Vehicles  will  consume  fuel  at 
rates  determined  by  par2uneters  in 
the  vehicle  parameter  database. 

I 

3.3.1 

The  fuel  consumption  rate  will  be 
reduced  when  a  vehicle  is  idling. 

I 

3. 3. 1.1 

Ground 

Vehicles 

Ground  vehicles  will  be  able  to 
move  forward,  backward,  and  turn. 

0 

3. 3. 1.1 

Vehicle  orientation  will  be 
determined  by  the  direction  and 
underlying  terrain. 

D 

3. 3. 1.1 

Environmental  factors,  including 
slope  and  terrain  type,  will  be 
considered  when  moving  the 
vehicle. 

D 

3. 3. 1.1 

The  following  hull  dynamics  models 
will  be  available  for  ground 
vehicles:  tracked  and  wheeled. 

D 

3. 3. 1.1 

Tracked  Ground  Vehicles  -  these 
vehicles  will  have  the  ability  to 
turn  in  place. 

D 

3. 3. 1.1 

Wheeled  Ground  Vehicles  -  these 
vehicles,  which  have  a  minimum 
turn  radius,  will  have  to  be 
moving  to  turn. 

D 

3. 3. 1.2 

Dismounted 

Infantry 

The  ModSAF  system  will  model 
dismounted  infantry. 

D 

3. 3. 1.2 

Each  soldier  will  be  able  to  carry 
and  use  a  weapon. 

D 

3. 3. 1.2 

Infantry  will  be  able  to  move  and 
turn  in  place. 

D 
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3. 3. 1.3  Fixed  Wing 
Aircraft 


3. 3. 1.4  Rotary  Wing 
Aircraft 


3. 3. 1.4 
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Infantry  have  the  special  ability 
to  mount  other  appropriate 
vehicles,  such  as  IFVs  or  large 
helicopters;  ride  in  them  to 
another  location;  and  dismount. 


While  mounted  in  a  vehicle,  the 
infantry  will  not  be  visible,  but 
will  be  vulnerable. 


Infantry  will  always  be  vertical 
when  standing  or  kneeling. 


Their  orientations  when  prone  will 
be  determined  by  the  underlying 
terrain. 


Fixed  wing  aircraft  (FWA)  will 
have  six  degrees  of  freedom. 


The  model  will  calculate  lift, 
drag,  and  thrust.  Effective 
limitations  on  roll,  pitch,  and 
yaw  rates  and  accelerations  will 
be  enforced. 


The  ModSAF  FWA  dynamics  software 
will  use  flight  data  from  Height- 
Mach  (H-M)  diagreuns  to  determine 
the  specific  power  which  is 
available  at  any  point  in  flight. 


Flight  data  from  V-N  diagreuns  will 
be  used  to  enforce  aerodyniunic  and 
structural  limits  on  lift  at  any 
int  in  the  flight  envelope. 


The  ModSAF  FWA  will  include  a 
simple  low  level  pilot  model  that 
can  turn  the  aircraft  to  follow  a 
velocity  vector,  perform  level 
flight,  and  follow  the  contour  of 
the  earth. 


The  rotary  wing  aircraft  (RWA) 
model  will  have  six  degrees  of 
freedom. 


Its  effective  performance  limits 
will  include  maximum  roll,  pitch, 
and  yaw  rates,  maximum  speeds, 
accelerations,  and  climb  rates. 
These  limits  may  be  expressed  in 
more  basic  parameters  such  as 
maximum  lift. 
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3. 3. 1.5 


The  MIA  model  will  include  a 
simple  pilot  model  that  is  able  to 
follow  a  velocity  vector,  perform 
level  flight,  contour  flight,  and 
nap  of  earth  flight. 


The  ModSAF  system  will  include  the 
following  missile  types:  (1) 
ground  to  ground,  (2)  Hellfire, 

(3)  long-range,  radar  guided,  air- 
to-air,  (4)  medium_range,  radar 
guided,  air-to-air.  and  (5)  short- 
ranae,  IR  ouided.  air-to-air. 


Ground  to  ground  missiles  (similar 
to  the  TOW  missile)  will  have  a 
slight  superelevation  angle  and  a 
METHurable  initial  velocity  upon 
firing.  They  will  fly  directly 
toward  the  target  along  a  line  of 
sight  flight  path  as  long  as  the 
line  of  sight  exists  between  the 
firing  vehicle  and  the  target. 

They  will  fly  over  encroaching 
terrain,  as  long  as  there  exists 
partial  line  of  sight  from  the 
firing  vehicle  to  the  target. 

They  will  be  able  to  coast  after 
the  powered  portion  of  the  flight 
is  finished. 
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3. 3. 1.5 


Hellflre  Missiles  (ground/air  to 
ground)  will  be  fired  with  a 
slight  superelevation  angle.  The 
missile  will  fly  out  along  its 
initial  trajectory  until  it  finds 
a  lased  target  point  to  trac)(  to. 
It  will  then  fly  toward  the  target 
in  the  X  Y  plane,  climbing  until 
it  achieves  a  predetermined  angle 
between  the  direction  of  travel  of 
the  missile  and  the  direct  vector 
to  the  target  point.  Maintaining 
this  angle  to  target  slowly  pulls 
the  missile  flight  angle  down  as 
the  missile  approaches  the  target. 
When  the  missile  passes  into  a 
conical  area  above  the  target 
point,  the  missile  will  fly 
directly  at  the  target  point  until 
impact.  This  missile  flight 
pattern  will  occur  as  long  as 
there  is  a  line  of  sight  between 
the  vehicle  doing  the  target 
designation  and  the  target,  and 
also  between  the  target  and  the 
missile.  The  missile  need  not  be 
powered  during  the  entire  flight. 
Note,  the  vehicle  that  fired  the 
missile  does  not  have  to  be  the 
vehicle  designatina  the  target. 


Long-Range,  Radar  Guided,  Air-To- 
Air  Missiles  (similar  to  the 
Phoenix  missile)  will  be  launched 
by  the  firing  vehicle,  and  will 
fly  straight  to  the  target  vehicle 
using  lead  pursuit  guidance.  The 
firing  aircraft  will  guide  the 
missile.  When  the  target  is  within 
the  tracking  capabilities  of  the 
Phoenix  missile,  the  missile  will 
turn  on  its  onboard  radar  and  will 
track  itself  to  target, 
independent  of  its  firing 
aircraft.  The  firing  aircraft 
roust  be  available  to  command  the 
missile  into  self  tracking  mode. 

If  the  firing  aircraft  is  not  able 
to  switch  the  missile  to  self 
tracking  mode,  then  the  missile 
will  not  lock  onto  a  target. 
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3. 3. 1.5 

Hediun-Range,  Radar  Qiid«d«  Air- 
To-Air  Missiles  (similar  to  the 
Sparrow  missile)  will  fly  toward 
their  targets  using  lead  pursuit 
guidance  as  long  as  the  firing 
aircraft  has  the  target 
illuminated  with  its  radar.  A 
position  change  by  the  firing 
aircraft  can  cause  the  missile  to 
lose  tracking.  An  example  is  a 
firing  aircraft  that  turns  away  so 
that  the  target  is  no  longer  radar 
Illuminated. 

D 

3. 3. 1.5 

Short-Range,  IR  Guided,  Air-To-Air 
Missiles  (similar  to  the 

Sidewinder)  must  be  locked  onto  a 
target  before  firing.  They  will 
fly  directly  toward  a  target  using 
pure  pursuit  guidance  as  long  as 
there  is  a  line  of  sight  between 
the  missile  and  the  target.  Once 
fired,  the  missile  is  self- 
tracking  (IR  seeking) . 

D 

3.3.2 

Entity  Turret 
Simulation 

The  ModSAF  system  will  allow 
vehicle  models  to  include  turrets. 

D 

3.3.2 

Turrets  will  be  able  to  rotate, 
elevate,  and  depress  any  mounted 
weapon  to  a  specified  limit. 

D 

3.3.2 

Turrets  will  scan  to  track 
targets,  and  when  the  vehicle  is 
not  engaging  an  enemy,  will 
occasionally  scan  to  a  different 
position  within  the  vehicle's  main 
arc  of  observation. 

D 

3.3.2 

Turret  parameters  (scan  rate  to  a 
position,  scan  limits,  and  the 
position  offset  to  the  attached 
hull)  will  k>e  defined  in  the 
vehicle  parameter  database. 

D 

3.3.3 

Weapons 

The  weapon  systems  for  each  entity 
will  be  specified  by  the  parameter 
database.  This  specification  will 
include:  weapon  position  on  the 
vehicle,  amount  of  amnunition 
available  to  each  weapon,  pre-fire 
time  delays  and  weapon  fire  rates, 
mount  information  (turret  or 
hull),  and  weapon  range  (area 
around  the  vehicle  that  the  weapon 
can  be  brought  to  bear  on) . 

I 
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3.3.3 

Weapon  types  will  include  missiles 
(which  are  visible  during  flyout 
and  produce  direct  fire),  indirect 
fire  weapons  (which  are  invisible 
during  flight),  and  direct  fire 
weapons  (which  are  invisible 
durina  flight) . 

3.3.3 

When  a  direct  fire  weapon  is 
fired,  a  hit  model  will  lE>e  used  to 
determine  if  the  shell  from  the 
weapon  will  strilce  the  target. 

I 

3.3.3 

The  hit  models  will  talce  into 
account  the  weapon  l^eing  used,  the 
firer's  velocity  and  range  to 
target,  the  target's  vehicle  type, 
aspect  angle,  velocity  and  percent 
exposure  (visibility) . 

I 

3.3.3 

These  factors  will  l>e  used  to 
determine  the  prolsability  of  the 
shot  hitting  the  target. 

I 

3.3.3 

This  probability  will  Ise  used  to 
determine  if  there  was  a  hit  or 
miss . 

I 

3.3.3 

I 

3.3.3 

When  a  particular  weapon  is  to  be 
used  (if  the  probability  is  not 
zero) ,  the  chance  that  this 
instance  of  the  eunmo/weapon  will 
be  a  dud  will  Ise  tested. 

I 

3.3.3 

If  it  is  a  dud,  there  will  be  no 
effective  impact  of  the  weapon 
system  on  the  target. 

I 

3.3.3 

If  the  dud  weapon  system  carries  a 
warhead  or  explosive  device  of 
some  )(ind,  there  will  Ise  no 
explosion. 

I 

■1 

Weapon  Firing 

Turret  mounted  weapons  will 
require  the  turret  to  trade  and 
elevate  relative  to  the  direction 
of  the  target. 

D 

3. 3. 3.1 

When  appropriate,  the  weapon 
system  will  lead  a  moving  target. 

■I 

■ 

Vehicles  will  stop  to  shoot  if 
required  (for  example,  the  M2  will 
stop  when  firing  a  TOW) . 

D 
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3. 3. 3. 2  Tactical 
Missiles 


3. 3. 3. 2 


3. 3. 3. 2 


3. 3. 3. 2 


3. 3. 3. 2 


3. 3. 3. 2 


3. 3. 3. 3  Ballistic 
Missiles 


3, 3. 3. 3 


3. 3. 3. 3 


3.3.4  Sensor 

Simulation 


3.3. 


Weapon  systems  will  have  the 
capability  to  fire  at  a  specific 
location.  Firing  may  occur  even 
if  no  particular  target  vehicle 
has  been  specified,  or  if  no 
potential  target  vehicle  exists  at 
or  near  the  specified  location. 


Missiles  will  have  a  parameter 
file  which  outlines  the 
performance  characteristics  of 
that  type  of  missile. 


These  characteristics  will  include 
targeting  methods,  warhead  types, 
flight  dynamics,  flight 
characteristics,  sensors,  modes, 
limitations,  movement  within  the 
dynamics  model ,  etc . 


Both  ballistic  and  battlefield 
missiles  will  be  ayailable. 


Missiles  can  be  targeted  and 
destroyed  by  weapon  systems 
designed  specifically  for 
destroyinq  missiles  in  fliaht. 


Tactical  missiles  will  haye  the 
capability  of  using  any  of  the 
following  guidance  algorithms, 
configured  in  the  parameter  files: 
lead-pursuit,  pure  lead,  and  pure 
pursuit . 


The  weapon  specification  will  also 
indicate  fuzing  distance,  minimum 
effectiye  distance  for  dcunage,  and 
maximum  tracking  angle  (outside  of 
which  target  tracking  will  be 
lost) . 


Ballistic  missiles  will  have 
aspects  of  their  launch  sequence 
user  definable. 


If  the  capabilities  of  the  missile 
provide  for  the  missile  to  get  to 
the  specified  point  from  its 
launch  position,  a  supplied  target 
point  will  automatically  control 
the  boost  phase  behavior  for  the 
missile. 


Parameters  that  can  be  specified 
for  ballistic  missiles  include 
initial  and  burnout  mass,  roll 
factors  (such  as  angle  and  start 
time',  thrust,  and  re-entry 
characteristics . 


Sensors  on  each  entity  will  be 
user  specifiable. 


Sensor  types  will  include:  visual, 
infrared,  and  radar. 
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3.3.4 


3.3.4 


_ DBSCKIPTIOM _ 

Parameters  appropriate  to  the 
sensor  type  may  consist  of  ranges, 
update  rates,  arcs  of  primary  and 
secondary  operation,  blind  areas, 
effective  distances,  and  chances 
of  detection. 

Sensors  will  determine  what  a 
vehicle  can  and  cannot  detect  in 
the  environment. 

Target  entities  will  be  tracked  if 
the  following  criteria  exist:  (1) 
the  entity  is  determined  to  be 
within  the  sensing  capabilities  of 
a  tracking  vehicle,  and  (2)  the 
target  entity  passes  tests  that 
determine  it  is  detectable. 


Probability  tables,  based  on 
orientation,  situation,  entity 
type,  line  of  sight,  angle  of 
incidence,  etc.  may  be  used  to 
determine  taraet  detectabilitv . 


A  radar  model  will  be  implemented 
which  calculates  the  radar  cross- 
section  of  a  target  based  upon  the 
target  type,  range  to  target,  and 
taraet  aspect  anale. 


If  the  radar  cross-section  of  a 
target  is  greater  than  a  threshold 
based  upon  the  given  radar's 
capabilities  and  mode,  then  that 
target  will  be  detected  by  the 
radar . 


The  radar  model  will  implement  the 
following  radar  modes  similar  to 
those  in  the  F-14D  AWG-9  radar: 
Pulse  Single  Target  Track  (PSTT), 
Pulse  Doppler  Single  Target  Track 
(PDSTT),  Track-While-Scan  (TWS) 
Manual,  and  Track-While-Scan  (TWS) 
Auto. 


The  PSTT  mode  will  also  be  used 
for  the  implementation  of  the 
lona-ranqe  missile  radar. 


The  radar  model  will  issue  the 
radar  protocol  data  unit  (PDU) 
defined  in  the  DIS  standard 
whenever  an  aircraft  or  missile 
radar  is  turned  on. 


An  interim  PDU  based  on  the  SIMNET 
Radar  PDU  will  be  used  until  this 
PDU  is  standardized  in  the  DIS 
Protocol  Standards. 


Mgra 

I 
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Visual  Model 


Infrared  (IR) 
Model 


A  visual  sensor  (eye)  model  will 
be  provided  that  takes  into 
account  effective  target  size  and 
occlusion  (actual  size,  aspect 
angle,  range,  percentage  visible), 
the  eyepoint  of  the  viewer,  the 
probability  of  detection,  and  the 
focus  of  attention. 


The  models  will  l>e  easily  extended 
to  support  different  illumination 
and  weather  conditions . 


The  IR  model  will  be  similar  to 
the  visual  model  but  will  include 
calculations  for  IR  signature 
strength  instead  of  effective 
taraet  size. 


Factors  for  IR  signature  strength 
will  include  thrust  levels  for 
aircraft,  aspect  angle,  and  entity 


3.3.5 


3.3.5 


Dcunage 


3.3.5 


3.3.6 


Entity 

Projections 


[leunage  models,  which  are  user 
specifiable,  will  define  how 
particular  weapons  affect  a 
particular  entity. 

D 

The  model  will  take  into  account 
the  following  factors:  angle  of 
incidence  of  the  impact,  which 
component  of  the  target  is 
affected,  and  the  number  of  rounds 
taken . 

D 

Missiles  will  be  subject  to  damage 
by  specifically  targeted  anti¬ 
missile  systems. 

D 

The  following  sections  list  the 
entity  appearances  that  will  be 
available  for  projection  onto  the 
simulation  network. 

I 
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3. 3. 6.1 

US  Entities 

The  American  entities  are  listed 
below. 

H 

3. 3. 6.1 

A6 

AlO 

ADATS 

AH-64A 

B52 

CG47 

Ch-47 

DD963 

DI 

F14D 

F18 

FFG7 

AH-IS 

HMMWV 

LHDl 

LOSAT 

MlAl 

M106A1 

M109 

M113A2 

Ml  13  ambulance 

M113  engineer 

M113 

M2 

M270 

M3 

M35A2 

M577 

M88A1 

M901 

M977 

M978 

MPQ  53 

OH  58C 

OH  58D 

UH  60A 

I 
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The  Threat  entities  are  listed 
below. 


BMP  1 
BMP  2 
DI 

GAZ  66 
MAZ  543 
Mi  8 
Mi  24 
Mi  28 
MIG  23 
MIG  29 
MTLB 

MTLB  ambulance 
SA  13 
SA  9 
SU  25 

SU  refueler 

T72 

T62 

T55 

UAZ  469 
URAL  375F 
ZIL  157 
ZSU  23-4 


Other  entities  are  listed  below. 


Gazelle 
LEO  2 
HARDER 

Water  Carrier 
Generic  Missile 


Behaviors  will  be  decomposed  into 
hierarchical  tasks. 


Tasks  will  use  entity, 
environmental,  and  internal  state 
to  generate  control  inputs  that 
guide  the  vehicle  in  accomplishing 
its  mission. 


Given  a  current  orientation, 
position,  and  velocity,  the 
vehicles  will  turn  and  move  toward 
the  goal. 


Multiple  points  can  be  sequenced 
together  to  Cotm  a  route.  A  route 
for  aircraft  will  be  a  simple  set 
of  these  points. 


When  requested  by  the  operator,  a 
route  between  two  terrain 
locations  can  be  automatically 
generated  for  use  by  ground  units 
and  entities. 


FARX 

3. 3. 7.1 


TITLE 


I 

I 

I 

I 


.3.7.1 


3. 3. 7.1 


3 


3 


3 


.3.7.2 


Resupply 


.3.7.2 


.3.7.2 


3. 3. 7. 2 


3 


.3.7.3 


Weapon 

Control 


3. 3. 7. 3 


3. 3. 7. 3 


3. 3. 7. 3 


3. 3. 7. 3 


_ DE8CRIFTIOW _ 

Ground  vehicle  routes  generated  by 
the  system  will  avoid  uncrossable 
rziver  segments. 

Road  routes  can  be  specified  by 
the  operator. 

If  a  road  route  is  requested,  a 
route  consisting  of  points  leading 
across  connecting  road  segments 
will  be  generated. 

Vehicles  will  have  the  capability 
to  handle  the  logistics  protocol. 
Vehicles  will  be  able  to  request 
supplies  from  a  logistics  vehicle. 
If  all  resupply  conditions  are 
satisfied,  logistics  vehicles  will 
refuel  and  rearm  at  the  x'ates 
specified  by  the  protocol. 

Vehicles  may  also  be  resupplied 
from  the  SAFstation  by  the 
Battlemaster . 

The  operator  will  be  able  to 
determine  the  situations  in  which 
a  vehicle  will  be  allowed  to  fire 
its  weapons.  Overall  fire 
permission  can  be  withheld. 

Fire  permission  can  be  granted 
under  the  following  conditions: 

(1)  the  target  is  within  a 
particular  distance  of  the  vehicle 
or  (2)  the  target  is  within  a 
particular  distance  of  a 
_desi2nated_^ointj________^^_^__ 

Fire  permission  can  also  be 
established  so  that  the  vehicle 
will  be  limited  only  by  the 
distance  limitations  of  the 
weapons  systems  of  that  vehicle. 
Targeting  characteristics  will 
allow  weapons  and  targets  to  be 
matched  in  order  to  select  the 
best  target  and  weapon  for  the 
situation  based  on  weapon 
capabilities,  weapon  priorities 
and  target  type,  distance  to 
target,  ammunition  availability, 
target  priority,  and  weapon 

enabled  lists. _ 

When  multiple  targets  are 
available  for  a  vehicle,  target 
selection  will  choose  the  most 
appropriate  target. 


3 


.3.7.3 


The  operator  will  have  the  ability 
to  establish  a  target  priority 
list  based  on  a  set  of  vehicle 
types . 


I 

I 

I 
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Ground 
Vehicle 
Specific 
Control  Tasks 


Air  Vehicle 
Specific 
Control  Tasks 


This  priority  list  will  aid  in 
target  selection  when  multiple 
taroets  present  themselves. 


Target  classes  available  will 
include  tanks,  command  vehicles, 
APCs,  rotary  wing  aircraft, 
artillery,  anti-aircraft  vehicles, 
logistics  vehicles,  fixed  wing 
aircraft,  missiles,  and  dismounted 
infantry. 


Vehicles  with  turrets  will 
occasionally  scan  their  turret 
either  through  an  arc  in  front  of 
the  vehicle  or  through  an  arc 
determined  by  the  vehicle's 
position  in  the  unit  formation. 
This  will  only  occur  when  the 
vehicle  is  alive  and  is  not 
firepower  disabled. 


The  following  commands  will  be 
generated  for  all  weapon  systems: 
place  the  weapon  in  the  correct 
firing  position,  fire  the  weapon, 
and  reload  the  weapon. 

Appropriate  delay  times  will  be 
utilized. 


Aircraft  will  be  able  to  perform 
single  target  beyond  visual  range 
(BVR)  air  to  air  tactics. 


Ground  vehicles  will  have  the 
capability  to  cross  bridges. 


Vehicles  will  slow  down 
automatically  and  line  up 
correctly  to  achieve  a  successful 
bridge  crossing.  After  crossing 
the  bridge,  vehicles  resume  their 
previous  speed  and  formation. 


Ground  vehicles  will  automatically 
avoid  obstacles  they  encounter  in 
their  paths.  Buildings,  unfordable 
river  segments,  and  tree  lines  (if 
desired)  will  automatically  be 
circumvented.  Other  vehicles  will 
also  be  avoided.  Direction  of 
travel  and  speed  of  these  vehicles 
will  be  taken  into  account  in 
avoidance  calculations. 


The  following  control  tasks  are 
supported  for  air  vehicles. 
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3. 3. 7. 5 

Takeoff  And  Land 

Air  vehicles  will  have  the  ability 
to  take  off  and  land.  The  aircraft 
model  will  handle  this  task 
automatically  under  the  following 
conditions:  (1)  a  vehicle  is 
tasked  to  move,  (2)  the  overall 
task  the  vehicle  is  performing 
requires  it  (such  as  returning  to 
base  to  resupply),  or  (3)  the 
operator  issues  a  request  (such  as 
flv  to  this  point  and  land) . 

D 

1 

Orient  Weapon  System 

Air  vehicles  will  have  the  ability 
to  realistically  orient  the 
airframe  in  a  desired  direction 
when  required  by  the  targeting 
requirements  of  a  particular 
weapon  system. 

D 

Collision  Avoidance 

Other  vehicles  will  be  avoided. 
Direction  of  travel  and  speed  will 
be  used  in  avoidance  calculations. 

D 

■ 

Bingo  Fuel 

A  bingo  fuel  level  will  be 
calculated  to  determine  the  time 
at  which  an  aircraft  must  end  its 
current  mission  and  return  to  the 
refuel  point.  The  distance  to  a 
operator  specified  refuel  point 
will  be  used  in  this  calculation. 

D 

3. 3. 7. 5 

Aircraft  Resupply 

When  a  predetermined  level  of  fuel 
remains,  rotary  wing  and  fixed 
wing  aircraft  will  aut<xnatically 
perform  the  appropriate  bingo  fuel 
maneuvers,  such  as  returning  to 
base.  Rotary  wing  aircraft  will 
be  able  to  use  FARP  locations  and 
will  do  the  proper  approach, 
landing,  exit,  request,  and 
transfer  procedures  automatically. 
Fixed  wing  aircraft  will 
automatically  be  refueled  and 
rearmed  when  landing  at  one  of  the 
defined  air  bases. 

D 
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3. 3. 7. 5 

Orbit  Hold 

Air  vehicles  will  have  the  ability 
to  perform  an  orbit  hold. 

Vehicles  will  perform  this  task  as 
a  single  task,  as  an  interrupt  to 
a  current  task,  or  as  the 
termination  task  of  other  tasks. 
Given  a  designated  point,  the 
vehicle  will  begin  to  circle  at  a 
fixed  distance  from  the  point  at  a 
standard  speed. 

D 

3. 3. 7. 5 

Racetrack  Hold 

Air  vehicles  will  have  the  ability 
to  perform  a  racetrack  hold. 
Vehicles  will  perform  this  task 
under  the  same  conditions  as  an 
orbit  hold.  Given  a  specified 
point  and  the  direction  that  the 
point  was  approached  from,  the 
vehicle  will  fly  to  the  point, 
turn  around,  and  head  back  in  the 
direction  it  came  from.  The 
vehicle  will  proceed  in  this 
direction  for  a  pre-determined 
time,  turn  around,  and  perform  the 
entire  maneuver  again. 

D 

3. 3. 7. 5 

Intercept 

Air  vehicles  will  have  the  ability 
to  turn  and  fly  a  course  which 
will  intercept  a  designated 
target . 

D 

3. 3. 7. 5 

Return  To  Base 

Air  vehicles  will  have  the  ability 
to  fly  to  a  point  designated  as 
their  base  of  operations.  Upon 
reaching  this  point,  the  vehicles 
will  land. 

D 

3. 3. 7. 5 

Evade 

Air  vehicles  will  have  the  ability 
to  turn  and  fly  a  course  that  will 
attempt  to  avoid  a  specific  enemy 
contact  or  contactr. . 

D 

3. 3. 7. 6 

Fixed  V/iny 
Aircraft 
Specific 
Control  Tasks 

The  following  control  tauks  are 
supported  for  fixed  wing  aircraft. 

I 

20  December  1993 


A-35- 


AppendLx  A 


3. 3. 7. 6 


Low-Level  Terrain  Flight 
(Automatic  Terrain  Following) 

Fixed  wing  aircraft  will  have  the 
ability  to  fly  routes  close  to  the 
ground.  In  doing  so,  the  vehicle 
will  attempt  to  maintain  the 
specified  required  altitude  above 
the  ground  but  will  tend  to  clip 
peaks  and  dips.  Low  level  flight 
will  be  characterized  by  a 
constant  speed  and  a  desired 
average  altitude  AGL. 


Takeoff  And  Land 

The  takeoff  and  land  control  task 
for  fixed  wing  aircraft  will  be 
unroodeled.  Fixed  wing  aircraft 
which  are  landing  will  set  their 
altitude  and  velocity  to  zero  upon 
achieving  correct  XY  locations  in 
soace . 


Jink 

Fixed  wing  aircraft  will  have  the 
ability  to  perform  sudden  changes 
of  flight  path.  Flight  path  angle 
and  direction  will  change.  FWA 
will  also  be  able  to  fly  toward  a 
point  while  performing  multiple 
i inks . 


Rotary  Wing  Contour  Flight 

Aircraft  Rotary  wing  aircraft  will  have  the 

Specific  ability  to  fly  contour  flight. 

Control  Tasks  Terrain  features  lying  in  the  path 
of  the  vehicle,  such  as  buildings, 
trees,  and  tree  canopies,  will  be 
flown  over  before  returning  to  the 
desired  close  to  around  altitude. 


Hover  Hold 

Rotary  wing  aircraft  will  have  the 
ability  to  perform  a  hover  hold. 
This  task  will  be  performed  under 
the  same  conditions  as  orbit  hold. 
The  vehicle  will  fly  to  the 
designated  hover  point,  come  to  a 
stop  in  the  air.  and  remain  there. 


The  SAFsim  will  be  able  to  create 
and  simulate  minefields. 


These  minefields  will  be  specified 
by  a  bounding  region,  the  type  of 
mine  contained  therein,  and  a 
density  of  mines. 


Each  minefield  can  have  a 
operator-specified  string  to 
identifv  it. 


Minefields 
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The  SAFsia  will  monitor  entities 
moving  within  the  minefield  and 
probabilistically  determine 
whether  a  mine  exolodes. 

D 

3.4.1 

The  minefield  will  be  capable  of 
being  breached,  and  areas  where 
mines  have  already  exploded  will 
not  explode  aaain. 

D 

3.4.2 

Buildings 

The  system  will  be  able  to  create 
buildings  in  the  simulation. 

Since  these  buildings  are  created 
by  the  simulation,  and  are  not 
part  of  the  terrain,  they  are  not 
permanent.  They  follow  the  seune 
rules  for  creation  as  entities, 
except  that  once  created,  they  can 
only  be  destroyed  or  removed  from 
the  simulation. 

N/I 

3.4.2 

A  building  cannot  move,  take 
commands,  or  perform  any  sort  of 
activity. 

N/I 

3.4.3 

Damage 

Simulation 

The  system  can  simulate  buildings 
taking  damage  from  direct  and 
indirect  fire,  and  a  destroyed 
building  will  be  displayed  under 
the  proper  circumstances. 

N/I 

3.4.3 

Damage  tables  will  exist  for 
buildings  in  the  par2uneter  files. 

N/I 

m 

Unit  Types 

The  types  of  ground  units 
simulated  will  include  at  least 
the  following: 

D 

1 

Mechanized  infantry  battalion, 
company ,  and  platoon 

Motorized  rifle  battalion, 
company,  and  platoon 

Armor  battalion,  company,  and 
platoon 

Armored  cavalry  troop 

Dismounted  infantry  section  and 
squad 

Artillery  battery  and  platoon 

Supply  platoon 

Mortar  platoon 

Air  defense  artillery  platoon 

D 

3.5.1 

Air  support  units  will  be  provided 
for  both  fixed-wing  aircraft  (FWA) 
and  rotary-wing  aircraft  (RWA)  in 
flights  of  one,  two,  three,  four, 
and  five  aircraft. 

D 

mm 

Both  attack  and  scout  RWA  will  be 
provided . 

H 

3.5.2 

Task 

Organization 

The  operator  will  have  the 
capability  to  create  units 
con^sed  of  entities  and/or  other 
units . 

D 
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3.5.3 


3.5.3 


3.5.3 
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The  operator  will  be  able  to 
specify  the  makeup  of  the  units, 
though  some  standard  units  will  be 
available. 


It  will  be  possible  for  the  ModSAF 
system  to  create  its  own  task- 
organized  units  without  operator 
intervention,  when  tactically 
aoDroDriate. 


CcMiimunication  The  SAFsim  will  model  message 

communications  between  the  HodSAF 
units  and  their  commanders. 


Information  will  be  aggregated  and 
messages  will  be  sent  to  the 
controlling  SAFstation  at  the 
level  of  command  of  the  unit  being 
simulated. 


The  rate  of  report  will  match  the 
battle  conditions. 


Units  will  have  the  ability  to 
collect  and  correlate  vehicle 
sighting  information  into  spot  and 
contact  reports. 


Other  messages  will  include 
artillery  impacts,  encounters  with 
minefields,  unit  task  transitions, 
and  unit  strenath  reports. 


These  communication  models  will 
also  be  used  to  send  CVCC  protocol 
packets  for  shell,  contact, 
status,  and  spot  reports. 


The  grouping  of  entities  into 
units  will  allow  the  operator  to 
control  multiple  entities  by 
giving  c^nmands  to  the  unit  as  a 
whole.  The  unit  will  then  perform 
the  specified  commands /tasks  as 
required.  These  tasks  may  involve 
independent  actions  by  sub-units 
or  entities. 


Sub-units  or  entities  in  a  unit 
may  also  be  directly  commanded  or 
tasked  separately  from  the 
remainder  of  the  unit. 


Applicable  tasks  will  support  both 
Threat  and  US  tactics. 


Tasks  for  ground  units  will 
include  at  least  the  followina: 


TEST 


Unit  Tasks 


Ground  Unit 
Tasks 


20  December  1993 


A-38- 


Appendix  A 


3. 5. 4.1 


3. 5. 4.1 


3. 5. 4.1 


3. 5. 4.1 


Ponutimt  K««pina  -  Vehicles  or 
DI  in  a  unit  will  have  the  ability 
to  move  in  formation  relative  to 
each  other.  A  variety  of 
appropriate  formations  will  be 
available  for  each  type  and  size 
of  unit.  The  coanander  will  be 
able  to  set  the  formation  scale 
factors  to  adjust  the  size  of  the 
formations.  Units  will  have  the 
capability  to  aut^aatically  adapt 
their  formation  to  their 
situation.  For  exaiiq;>le,  as  a  unit 
arrives  at  a  river  bridge,  the 
member  vehicles  of  that  unit  will 
fall  out  of  formation  as  each 
approaches  the  bridge,  will  form  a 
column  to  cross  the  bridge,  and 
will  return  to  their  original 
formation  on  the  other  side.  This 
behavior  will  also  occur  when 
units  skirt  terrain  features,  such 
as  rivers  or  treelines,  or 
negotiate  passages  too  small  to 
accommodate  the  original 
formation. _ 


Command  From  Simulator  -  ModSAF 
ground  units  will  have  the  ability 
to  be  commanded  by  manned 
simulators.  The  manned  simulators 
will  take  the  place  of  the  unit 
commander  vehicle,  and  will  always 
be  the  lead  vehicle  of  the  unit. 


Follow  Vehicle  -  ModSAF  ground 
units  will  have  the  ability  to 
follow  manned  simulators.  The 
manned  simulators  will  always  be 
the  lead  vehicle  of  the  unit. 


Bounding  Overwatch  -  Ground 
vehicles  and  dismounted  infantry 
will  be  able  to  perform  bounding 
overwatch  movement,  in  which  a 
portion  of  the  unit  covers  the 
movement  of  another  portion  of  the 
unit,  using  terrain  features  as 
cover . 
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Tim 


3. 5. 4. 2  Air  Unit 
Tasks 


3. 5. 4. 2 


Targeting  Coordination  -  Vehicles 
in  a  unit  will  have  the  capability 
to  coordinate  their  fire  with 
multiple  targets.  For  exaiqple,  a 
US  tank  platoon  of  Mis  presented 
with  multiple  targets  will  each 
shoot  at  a  target  that  has  not 
already  been  chosen  by  another 
member  of  the  platoon.  This  will 
occur  only  with  units  that  do  this 
sort  of  coordinated  fire  (i.e.,  US 
units),  and  only  at  the  basic 
platoon  level. 


Hasty  Attack  - 

Ground  units  will  automatically 
perform  a  hasty  attack  when  they 
come  under  fire,  have  fire 
permission,  and  are  on  the  move. 


Tasks  for  air  units  will  include 
at  least  the  following: 


Formation  Keeping  -  Vehicles  in  a 
unit  will  have  the  ability  to  move 
in  formation  relative  to  each 
other.  A  variety  of  appropriate 
formations  will  be  available  for 
each  type  and  size  of  unit. 


Targeting  Coordination  -  Vehicles 
in  a  unit  will  have  the  capability 
to  coordinate  their  fire  at 
multiple  targets.  This  will  occur 
only  with  units  at  the  basic 
flioht  level. 


FWA  Ground  Attack  - 
FWA  units  will  have  a  standard  set 
of  ground  attacks  available,  with 
a  variety  of  operator-selectable 
options.  The  unit  will  perform  an 
ingress  using  any  method  and 
formation  normally  available  for 
route  following.  The  flight  will 
then  do  one  of  the  following 
actions:  go  straight  to  the  target 
area  in  a  direct  attack,  spread 
out  into  a  line  and  do  a  trailing 
attack,  or  split  up  and  do  either 
a  split  or  a  ninety /ten  attack. 
Attack  entry  points  can  also  be 
selected  as  either  level  or  pop-up 
attacks,  or  standoff  pop-up  and 
dive  attacks.  Available  delivery 
methods  for  the  attack  will  be 
laydown,  strafe,  medium-altitude 
dive,  or  low-altitude  dive. 
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RWA  Ground  Attack  -  RWA  units  will 
have  two  predefined  ground  attack 
patterns,  hover-fire  and  running- 
fire.  For  both,  the  aircraft  will 
approach  the  target  area  slowly  at 
very  low  altitude  to  avoid 
detection.  In  a  hover-fire 
attack,  the  vehicles  move  into  (or 
approach  in)  an  extended  line 
formation.  Each  aircraft  will  then 
pop  up  until  a  target  is  acquired, 
fire  at  that  target,  move  back 
down,  then  move  laterally  and  pop 
up  and  fire  again.  This  will 
continue  until  all  targets  in  the 
designated  area  have  been 
destroyed.  In  a  running-fire 
attack,  the  rotary  wing  aircraft 
will  move  to  attack  speed,  flying 
straight  toward  the  target  area, 
fire,  and  then  retreat.  Each 
aircraft  will  either  make  the  run 
once  only  or  make  multiple  runs, 
as  specified  bv  the  commander. 

D 

3.5.5 

Unit  Task 
Frames 

The  user  will  create  missions  for 
the  units  he  controls  by  combining 
and  editing  sequences  of  task 
frames.  Unit  task  frames  will  be 
created  from  unit  tasks.  This 
section  lists  the  unit  task  frames 
that  will  be  defined  in  the  ModSAF 
system. 

I 

3.5.5 

The  operator  will  select  generic 
task  frames;  the  specific  task 
frames  that  will  be  executed  are 
determined  by  the  unit  (echelon 
and  tactics,  i.e.  US  or  Threat) 
that  they  are  assigned  to.  Some 
task  frames  will  not  apply  to  all 
units. 

I 

3.5.5 

The  tasks  that  compose  a  task 
frame  have  many  parameters  with 
default  settings.  The  user 
customizes  the  task  freunes  that  he 
uses  by  editing  these  parameters, 
which  include  speeds,  formations, 
messages,  rules  of  engagement, 
etc . 

I 

3. 5. 5.1 

Ground  Unit 
Task  Frames 

Ground  Unit  task  frames  components 
will  include: 

■1 
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TITUS 


3. 5. 5. 2  Rotary  Wing 
Aircraft 
(RWA)  Task 
Fr2unes 


3. 5. 5. 2 


3. 5. 5. 2 


3. 5. 5. 2 


3. 5. 5. 2 


3. 5. 5. 2 


niSCRIPTIOH 


Assault /Attack 
Clear  Area 
Halt 

Occupy  Ambush 

Hasty  At tack/ Act ion  Drill 

Occupy  Assembly  Area 

Occupy  Battle  Position 

Pre-battle  March 

Random  Traffic 

Reconnoiter 

Roadmarch 

Tactical  March 

Withdraw 


The  ModSAF  software  will  be 
capable  of  performing  the 
following  task  frames  for  RWA 
units : 


Occupy  Assembly  Area  -  A  unit  will 
fly  to  the  center  of  an  area  and 
land  in  an  occupy  assembly  area 
formation.  This  formation 
maximizes  the  chance  of  detecting 
enemy  contact  from  any  direction, 
and  the  chance  of  escape  of  some 
of  the  unit  if  surprised. 


Occupy  Battle  Position  -  A  unit 
will  fly  to  a  position  and  hold  in 
an  occupy  battle  position 
formation.  The  battle  position 
formation  allows  mutual  support 
and  early  detection  of  any  enemy 
contact.  The  direction  of 
expected  contact  will  be  the 
orientation  of  the  formation. 


Fly  Enroute  -  A  unit  will  fly 
along  a  route,  with  one  particular 
vehicle  following  the  route,  and 
the  other  vehicles  in  the  unit 
maintaining  predetermined 
formation  positions  relative  to 
the  leading  vehicle  or  each  other. 


Aerial  Fire  Support/Close  Air 
Support  -  Units  will  fire  at 
ground  targets  in  a  designated 
area. 


Return  To  Base  -  Rotary  wing 
aircraft  units  will  have  the 
ability  to  fly  to  a  point 
designated  as  their  base  of 
operations.  Upon  reaching  this 
point,  the  vehicles  will  land. 
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3. 5. 5. 3 


3. 5. 5. 3 


DUCKZPTIttl 


FARP  Behavior  -  Rotary  wing  units 
will  have  the  ability  to  perform 
the  proper  FARP  behaviors .  The 
unit  will  fly  to  a  point  a  few 
kilometers  from  the  resupply 
point,  then  drop  down  to  a  low 
altitude,  and  fly  nap  of  earth  or 
low  level  flight  to  the  resupply 
point.  The  aircraft  will 
automatically  query  the  vehicles 
in  the  supply  area  for  needed 
supplies,  and  will  land  and 
perform  the  resupply  procedures. 
When  done,  vehicles  will  leave  the 
area,  again  using  low  level  or  nap 
of  earth  flight  till  they  are 
again  a  few  kilometers  from  the 
resupplv  area. 


Hold  -  RWA  units  will  have  the 
ability  to  do  hover,  orbit,  and 
racetrack  holds.  Hover  holds  will 
be  accomplished  by  the  leader 
coming  to  a  stop  at  a  particular 
location,  and  the  rest  of  the  unit 
moving  into  proper  formation 
positions  relative  to  the  leader 
and  each  other.  For  an  orbit 
hold,  the  vehicles  will  trail  the 
lead  vehicle  as  they  move  around 
the  orbit  circle.  For  the 
racetrack  hold,  vehicles  will 
maintain  formation  positions,  and 
will  follow  the  lead  vehicle 
around  the  racetrack  route  as  if 
following  the  lead  vehicle  on  a 
normal  route. 


The  ModSAF  software  will  be 
capable  of  performing  the 
following  task  frames  for  FWA 
units : 


At  Airport  -  Aircraft  will  remain 
on  the  ground  and  will  not  move. 
Vehicles  will  be  resupplied  while 
performing  this  mission. 


Ingress  - 

Unit  will  follow  a  route  into  a 
target  area.  Targets  of 
opportunity  should  not  be 
approached.  This  should  be  used 
before  an  Attack  Ground  Targets 
mission. 


nST 


N/I 
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Ground  Unit 
Reactions 


3.5.6, 


DESCRIPTION 


Attack  Ground  Targets  -  The  unit 
will  perform  the  appropriate 
predetermined  ground  attack  tasks, 
chaining  together  approach,  entry, 
de.ivery,  and  egress.  The  proper 
(but  not  required)  mission  to 
approach  an  attack  target  ground 
mission  is  an  ingress,  and  if 
used,  the  unit  will  proceed  to  an 
egress  mission  when  the  attack  is 
finished.  For  options,  see  Air 
Unit  Tasks,  FWA  Ground  Attack. 


Egress  -  Unit  will  follow  a  route 
out  of  a  target  area.  Targets  of 
opportunity  can  be  approached. 
This  should  be  used  after  an 
Attack  Ground  Targets  mission. 


Fly  Enroute  -  Unit  will  fly  along 
a  route,  with  the  lead  vehicle 
following  the  route,  and  the  other 
members  of  the  unit  stationkeeping 
off  the  leader  or  each  other  as 
appropriate . 


Combat  Air  Patrol  -  The  unit  will 
patrol  an  area,  awaiting  orders  or 
targets  of  opportunity. 


Hold  -  FWA  units  will  have  the 
ability  to  do  orbit  and  racetrack 
holds.  Orbit  holds  will  be 
accomplished  by  the  vehicles 
trailing  the  lead  vehicle  as  they 
move  around  the  orbit  circle.  For 
racetrack  holds,  vehicles  will 
maintain  formation  positions  and 
follow  the  lead  vehicle  around  the 
racetrack  route  as  if  following 
the  lead  vehicle  on  a  normal 
route . 


The  SAFsim  will  implement 
automatic  reactive  behaviors. 
ModSAF  vehicles  of  different  types 
will  have  unique  sets  of  reactive 
behaviors  for  different  situations 
and  battlefield  events.  Reactions 
will  be  in  addition  to  tasked 
behaviors.  Reactions  will  include, 
but  not  be  limited  to  the 
behaviors  listed  below. 


The  ground  unit  reactions  will 
include  the  following: 


Action  Drill  /  Hasty  Attack  - 
Triggered  by  contact  with  enemy 
units  of  appropriate  size, 
position,  and  activity  when  the 
unit  has  permission  to  engage. 


TEST 


N/I 
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3. 5. 6.1 

Hasty  Withdraw  -  This  reaction 
will  occur  when  the  unit  has  no 
fire  permission  and  comes  under 
fire  from  another  unit. 

N/I 

3. 5. 6.1 

React  To  Air  Raid  -  The  unit 
reacts  when  taking  fire  from  an 
enemy  aircraft  and  not  attacking. 
The  unit  will  scatter  and  vehicles 
will  take  cover  if  it  is 
available . 

N/I 

3. 5. 6.1 

Avoid  Enemy  Contact  (while  covered 
or  in  open)  -  The  unit  will  try  to 
find  a  place  to  hide,  or  if 
already  hidden,  will  remain  in 
place  until  the  air  contact  is 
broken . 

N/I 

3. 5. 6.1 

Withdraw  from  Minefield  - 
Triggered  when  a  unit  encounters 
a  mine.  The  unit, assuming  a  tank 
trap,  may  issue  covering  fire  and 
then  back  out  of  the  minefield 
until  covered  from  potential  fire 
by  intervening  terrain  or  by 
terrain  features  such  as  trees  or 
buildings . 

D 

3. 5. 6.1 

React  to  Artillery  -  Unit  will 
seek  cover. 

D 

3. 5. 6. 2 

Rotary  Wing 

Aircraft 

(RWA) 

Reactions 

The  following  reactions  will  be 
included  for  ModSAF  RWA: 

D 

3. 5. 6. 2 

React  To  Enemy  FWA  Attack  -  Unit 
will  turn  into  the  approaching 
enemy  FWA  and  then  fly  as  fast  and 
as  low  as  possible  in  order  to  cut 
their  firing  angles.  Once  behind 
the  enemy  FWA,  the  surviving  RWA 
will  turn  around  and  fire  on  the 
enemy  aircraft. 

N/I 

3 .5.6.2 

React  To  Enemy  RWA  Attack  -  RWA  in 
the  unit  will  scatter  in  the 
opposite  direction  of  the 
attacking  aircraft,  and  will 
rendezvous  at  a  distance  from  the 
initial  position. 

N/I 

3. 5. 6. 2 

Evade  -  The  unit  will  turn  away 
from  the  air  defense  unit  and  get 
as  low  as  possible,  flying  away 
from  the  fire  or  radar.  At  a  safe 
distance,  the  unit  will  regroup 
and  either  Hold  Awaiting 
Instructions  or  resume  its 
mission. 

N/I 
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3. 5. 6. 3  Fixed  Wing 
Aircraft 
(FWA) 

Reactions 


3. 5. 6. 3 


TITLE  I  DB8CRIPTI(»r 


Bingo  Fuel  -  The  vehicle  will 
monitor  its  fuel  load  and  the 
distance  from  base  or  refuel 
location.  If  the  critical  fuel 
level  is  reached,  the  vehicle  will 
return  to  base. 


The  ModSAF  software  will  be 
capable  of  performing  the 
following  FWA  reactions: 


Bingo  Fuel  -  The  vehicle  will 
monitor  its  fuel  load  and  the 
distance  from  base  or  refuel 
location.  If  the  critical  fuel 
level  is  reached,  the  vehicle  will 
return  to  base. 


Evade  -  The  unit  will  turn  away 
from  the  air  defense  unit  and  fly 
away  from  the  fire  or  radar.  If 
enemy  fire  is  shell  fire,  the  unit 
will  try  to  gain  altitude.  At  a 
safe  distance,  the  unit  will 
regroup,  and  either  Hold  Awaiting 
Instructions  or  resume  its 
mission. 


The  SAFsim  will  provide  a  parser 
interface  with  the  following 
capabilities 

for  testinq  SAF  software: 


a  limited  set  of  command  line 
instructions  for  controlling  the 
ModSAF  system  and  vehicle 
debuaainq 


the  capability  to  turn  debugging 
code  on  and  off  in  the  SAFsim 


the  capability  to  query  the  status 
of  executing  tasks  and  units  in 
the  simulation  exercise 


Database  The  SAFsim  will  obtain  information 

Interfaces  from  the  followin'  databases: 

Terrain  Database,  Persistent 
Object  Database,  DIS  Database,  and 
Parameter  Database .  These 
databases  are  described  in  Chapter 
5. 


Graphical  The  ModSAF  data  logger  will 

User  provide  a  GUI  for  user 

Interface  interaction.  The  GUI  will  use 

(GUI)  X/Windows  and  Motif,  and  provide 

access  to  all  features  that  the 
data  loqqer  supports. 


nsT 
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Exercise 

Recording 

The  ModSAF  data  logger  will  be 
able  to  record  the  simulation 
packets  of  any  protocol  family 
transmitted  on  the  simulation 
network.  These  include  the  DIS, 
Persistent  Object  (PO),  SIMNET, 
and  Data  Collection  protocols. 

The  GUI  will  allow  the  user  to 
select  which  protocol  families  to 
record.  It  will  also  allow  the 
user  to  specify  the  exercise  ID, 
exercise  start  time  and  date,  and 
the  file  name  under  which  the 
exercise  will  be  saved.  A  compact 
data  storage  format  will  be  used, 
so  that  large-scale  exercises  that 
last  many  hours  can  be  recorded 
into  a  single  file.  The  data  will 
be  recorded  in  such  a  way  as  to 
allow  random  access  into  the 
recorded  exercise. 

D 

4.2 

The  ModSAF  data  logger  will 
display  exercise  statistics  on  the 
GUI  in  real  time  while  an  exercise 
is  being  recorded.  These 
statistics  will  include  the 
exercise  packet  rate,  exercise 
entity  count,  logger  data  file 
size,  and  elapsed  exercise  time. 

D 

4.2 

The  ModSAF  data  logger  will 
support  a  studio  mode  that  allows 
recording  into  multiple  logger 
files  simultaneously,  playback  of 
multiple  logger  files 
simultaneously,  and  editing  and 
splicing  of  logger  files. 

D 

4.2 

The  ModSAF  data  logger  will 
provide  an  automatic  shut-off 
feature  that  can  be  used  to  stop 
recording  or  playback  at  a  user- 
specified  time.  This  will  have 
the  same  effect  as  pressing  the 
•stop*  button  at  the  specified 
time . 

D 

4.3 

Exercise 

Playback 

The  ModSAF  data  logger  will  be 
able  to  play  back  the  simulation 
packets  of  any  protocol  family 
recorded  in  a  ModSAF  data  logger 
file.  These  include  the  DIS, 
Persistent  Object  (PO),  SIMNET, 
and  Data  Collection  protocols. 

The  GUI  will  allow  the  user  to 
select  which  protocol  families  to 
plav  back. 

D 
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The  ModSAF  data  logger  will 
display  exercise  statistics  on  the 
GUI  in  real  time  while  an  exercise 
is  being  played  back.  These 
statistics  will  include  the 
exercise  packet  rate,  exercise 
entity  count,  logger  entity  tick 
rate,  elapsed  exercise  time,  and 
remaining  exercise  time. 


The  ModSAF  data  logger  will  be 
able  to  play  back  a  data  logger 
file  on  any  exercise  ID, 
regardless  of  the  exercise  ID  on 
which  the  file  was  recorded.  The 
ModSAF  data  logger  will  support 
modification  of  entity  simulation 
IDs,  so  that  multiple  exercises 
can  be  played  back  simultaneously 
without  interference. 


The  ModSAF  data  logger  will  be 
able  to  play  back  in  forward  and 
reverse  directions.  The  ModSAF 
data  logger  will  be  able  to  play 
back  an  exercise  either  in  real 
time,  up  to  50  times  faster  than 
real  time,  or  up  to  10  times 
slower  than  real  time.  It  will 
compensate  for  first  order  dead 
reckoning  of  entities  so  that  they 
appear  to  move  smoothly  even  when 
being  played  back  at  speeds  other 
than  real  time. 


The  ModSAF  data  logger  will  be 
able  to  make  an  exercise  pause 
during  playback  without  causing 
the  entities  to  time  out  on  the 
simulation  network.  The  ModSAF 
data  logger  will  be  able  to  play 
back  a  user-specified  portion  of 
an  exercise  repeatedly  (loop 
plav)  . 


Initializ-  Since  all  ModSAF  command  and 
ation  of  control  information  is  sent  via 

ModSAF  from  a  the  PO  protocol,  the  ModSAF  data 
Logged  logger  will  be  recording  the  state 

Exercise  of  the  missions  that  ModSAF 

entities  are  executing  throughout 
an  exercise.  The  ModSAF  data 
logger  will  record  PO  protocol 
packets  in  such  a  way  as  to  allow 
initialization  of  ModSAF  from  any 
point  in  a  logged  exercise.  The 
recording  will  not  interfere  with 
the  normal  operation  of  the 
simulation. 
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4.4 

The  ModSAF  data  logger  will 
provide  an  interface  for 
generating  a  ModSAF  scenario  file 
at  any  point  during  playback.  The 
scenario  file  generated  can  then 
be  used  to  initialize  ModSAF 
entities  from  that  point  in  the 
exercise.  This  interface  will 
allow  ModSAF  entities  to  be 
initialized  fr<»n  any  point  in  the 
exercise  without  having  to  replay 
the  entire  exercise  up  to  that 
point . 

D 

5.1 

DIS  Database 
Interface 

The  ModSAF  software  will  support 
the  DIS  1.0  protocol,  with 
appropriate  extensions  necessary 
for  ModSAF,  such  as  radar  packets. 
All  applicable  DIS  packets  (entity 
state,  events,  exercise  control, 
appearance,  impact,  status,  etc.) 
will  be  supported.  In  accordance 
with  the  DIS  standard,  each  entity 
will  broadcast  state  at  least  once 
every  five  seconds,  and  more  often 
if  required  by  dead  reckoning 
algorithms.  The  DIS  network 
interface  layers  will  be  UDP/IP. 

D 

5.1 

The  ModSAF  software  will  also 
support  the  SIMNET  6.6.1  protocol 
using  the  SIMNET  association  layer 
as  the  network  interface  layer. 

D 

5.1 

The  network  drivers  will  be  in  a 
small,  well-defined  interface 
module  to  enhance  portability 
across  operating  systems  and 
computers. 

D 

5.2 

PO  Database 
Interface 

The  following  requirements  apply 
to  the  Persistent  Object  (PO) 
database : 

I 

5.2 

It  will  support  large  numbers  of 
hosts . 

D 

5.2 

It  will  support  real-time 
performance . 

■I 

5.2 

It  will  be  able  to  recover  from 
missed  packets. 

■1 
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Command  and 
Control 


Command  and 

Control 

Overlays 


It  will  support  migration  of 
simulation  objects  from  one 
simulation  cnaputer  to  another.  It 
will  be  possible  for  simulation 
objects  to  migrate  at  the  user's 
command.  It  will  be  possible  for 
simulation  objects  to  migrate 
automatically  during  simulation 
and  entity  creation,  either  for 
load  balancing  or  graceful 
recovery  when  a  simulator  times 
out. 


It  will  support  thousands  of 
database  objects  that  change 
infrequently  (less  than  two  or 
three  times  per  minute) .  Objects 
will  rebroadcast  with  a  30-second 
timeout  period  for  an  initial 
period.  Source-based  filtering 
will  be  used  to  reduce  steady- 
state  oacket  rates. 


It  will  support  query-driven  and 
event-driven  interfaces . 


The  PO  database  will  support 
representations  of  order  of  battle 
information,  orders  including 
missions  and  graphics, 
intelligence,  reports  and 
messages,  H-hours,  and  other 
information  required  to  set  up 
exercises  and  control  their 
participants . 


The  capability  to  organize  command 
or  exercise  information  into 
overlays  and  share  that 
information  between  workstations 
will  be  provided.  These  overlays 
will  store  unit  and  entity 
locations,  unit  and  entity 
missions,  possible  enemy  locations 
and  other  intelligence 
information,  and  mission-specific 
information  (including  graphics 
and  routes) .  Sharing  of  overlays 
will  be  possible  only  eunong 
workstations  playing  on  the  same 
side  in  an  exercise. 
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5.3 

Parameter 

I}atabase 

Interface 

System  and  performance  parameters 
will  be  defined  in  public 
parameter  files,  which  will  be 
used  to  initiate  a  runtime 
parameter  database.  This  database 
can  be  changed  at  runtime  by  the 
user  or  the  system,  and  will  allow 
modification  of  models  without 
recompiling  source  code.  The  types 
of  parameters  defined  in  the 
public  files  are  described  below. 

D 

5.3.1 

Organiz¬ 

ational 

Parameters 

The  organizational  parameters  will 
define  the  organic  echelons  and 
formations  used  by  the  SAP  units. 
These  echelons  can  be  grouped  to 
define  new  unit  types. 

D 

5.3.2 

Entity 

Parameters 

The  entity  parameters  will  specify 
characteristics  of  SAF  entities 
and  define  the  component  physical 
models  and  weapons  systems  for 
each  SAF  entity.  The  network 
entity  types  are  defined  in  the 
simulation  protocol  files,  but 
variations  of  these  entities  can 
be  created  in  the  pareuneter  files. 
The  following  entity  information 
can  be  specified  in  these  files: 

I 

5.3.2 

Network  representation 

Alignment,  identity,  and  function 
of  entity 

Weapons  carried  by  entity 

Dyncunics  model  parameters 

Damage  models  for  direct  and 
indirect  weapons 

Standard  fuel  and  ammunition  loads 
Detection  probabilities 

I 

5.3.3 

Weapon 

Parameters 

The  weapon  parameter  files  will 
specify  characteristics  of 
different  weapons  systems.  The 
following  weapon  system 
information  can  be  specified  in 
these  files: 

I 

5.3.3 

Characteristics  of  projectile 
weapons  (munition,  range,  round 
velocity,  mass) 

I 

5.3.3 

Characteristics  of  missiles 
(acceleration,  maximum  speed, 
maximum  range,  guidance  model, 
default  elevation,  mass,  dud 
probability) 

I 

5.3.3 

Hit  probabilities 
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5.3. 
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Behavioral 

Parameters 


5.3.5 


User 

Interface 

Par2uneters 


Sensor 

Parameters 


Exercise 

Parameters 


Terrain 

Database 

Interface 


pnov 


The  behavioral  parameter  files 
will  define  parameters  for  the 
various  behavioral  tasks, 
specializing  them  for  lifferent 
units  and  situations.  T^^ks  and 
their  parameters  will  aJ  :o  be 
organized  into  task  frames  to 
define  tactics  and  mission 
comoonents . 


The  user  Interface  parameter  files 
will  define  parameters  for  the 
user  interface.  These  will 
include: 


Unit  icons  and  entity  pictures 


Graphics  attrilxites  (color,  line 
types) 


Size  of  panes  for  map,  messages, 
and  editor 


Control  Measures 


Coordinate  conversion 


The  sensor  parameter  files  will 
define  the  parameters  for  the 
various  sensor  systems  modeled  in 
ModSAF.  These  will  include: 


e  of  sensor 


Capabilities  of  sensor 


The  exercise  parameter  files 
define  parameters  used  to  control 
the  ModSAF  system  in  the  context 
of  a  simulation  site.  This 
includes  the  site/host  information 
for  each  SAF  component. 


The  terrain  databases  will  support 
the  following  queries: 


TB8T 


Terrain  elevation  cross  section 


Elevation  and  orientation  f 
entity  placement 


Soil  type 


Coordinate  conversion  between  UTM, 
latitude/ longitude,  earth-centered 
Cartesian  and  local  coordinates 


Basic  terrain  feature  data  and 
attributes,  including  roads, 
rivers,  buildings,  lakes,  and 
trees 


Road  and  river  networks 


Local  terrain  features  for  terrain 
reason in 
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Terrain  Data 


5.4.2 


While  multiple  databases  may  be 
used  at  runtime  for  different 
purposes,  they  will  all  be 
automatically  generated  from  a 
single  common  source  file  to 
ensure  correlation. 


The  terrain  database  will  include 
the  soil  types  (road,  muck,  deep 
water,  shallow  water,  packed  dirt, 
soft  dirt,  sand,  forested,  etc.) 
at  each  point.  Altitude  and  slopes 
will  be  included.  While  a  regular 
grid  system  may  be  used,  it  will 
also  be  possible  to  describe  and 
use  irregular  grids  of  larger  or 
smaller  size  Cmicroterrain”) . 


Cultural  Data  The  terrain  database  will  be 

capable  of  representing  at  least 
the  following  cultural  data: 
primary  roads,  secondary  roads, 
bridges,  railroads,  buildings . 
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ARPA 

ATP 

AVTB 

BDS-D 

CGF 

LADS 

CDRL 

MWTB 

DI 

DIS 

GUI 

ModSAF 

SAP 

SAPOR 

SAPsim 

SAPstation 

SPR 

SOW 


Gloaaary  of  Acronyms  and  Abbreviations 

Advanced  Research  Projects  Agency 

Acceptance  Test  Plan 

Aviation  Test  Bed,  Pt  Rucker,  Alabama 

Battlefield  Distributed  Simulation  >  Developmental 

Computer  Generated  Forces 

Loral  Advanced  Distributed  Simulation 

Contract  Data  Requirements  List 

Mounted  Warfare  Test  Bed,  Ft.  Knox,  Kentucky 

Dismounted  Infantry 

Distributed  Interactive  Simulation 

Graphical  User  Interface 

Modular  Semi-Automated  Forces 

Semi-Automated  Forces 

Semi- Automated  Forces 

ModSAF  Simulator  Subsystem 

ModSAF  user  interface  workstation 

Software  Problem  Report 

Statement  of  Work 
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